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ABSTRACT 


The capability of an autonomous underwater vehicle (AUV) to rendezvous with 
other AUVs was implemented and demonstrated in the Naval Postgraduate School 
ARIES AUV; providing a method of overcoming the severe range limitations of high- 
bandwidth underwater data transfer methods in order to enable accelerated access to data 
collected by a network of data-gathering survey AUVs. Rendezvous was implemented by 
autonomous reconfiguration of ARIES’ operations, using a mission planning module to 
combine acoustically-transmitted rendezvous requests from survey AUVs with pre-stored 
survey AUV mission data to generate rendezvous missions based either on time-optimal 
or energy-optimal trajectories. The planning module efficiently generates rendezvous 
trajectories based on solutions derived using optimal control theory. A new third layer of 
control, based on a finite state machine, was added above ARIES’ autopilot and mission 
execution functions in order to initiate mission planning and replanning, activate 
missions, sequence vehicle operations through seven defined states, control acoustic 
communications, and handle perturbations and missed rendezvous. 
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I. INTRODUCTION 


A. MOTIVATION 

This work furthers the capabilities of an evolving class of robot, the autonomous 
underwater vehicle (AUV). AUV’s represent the latest development in a centuries-old 
progression of human efforts to work in the marine environment, efforts motivated by 
economic, scientific, military, and other reasons. 

Work in the marine environment is difficult on many levels. Human operators are 
out of their natural element and require protection and life support. Communications 
bandwidth and range are more limited than for most other environments. This 
complicates the control of underwater systems, and can result in loss of the system due to 
an inability to communicate with or locate it. Significant forces such as winds, waves, 
currents, and hydrodynamic and hydrostatic forces affect and disrupt operations. The 
environment is corrosive, fouling, and incompatible with electrical/electronic equipment. 
As a result, operations tend to be difficult, time consuming, expensive, and hazardous to 
both machine and operator. 

AUVs are a recent solution for achieving desired objectives in the marine 
environment while addressing and overcoming the inherent challenges. As technology in 
any field of work advances, it is leveraged to maximize benefit and minimize cost. The 
same is true in this context. Beginning with boats and nets, human ingenuity has 
extended man’s presence and capabilities in the marine environment to maximize 
benefits while reducing the costs and risks of doing so. Advances in technology brought 
successive improvements in marine propulsion; progressing from oars, to sails, to steam, 
to nuclear and other current methods of propelling vehicles delivering cargo, warheads, 
sensors, or other payloads. Sensors evolved from the lead line, used for taking 
soundings, to sonar for taking soundings and locating objects other than the sea floor, to 
high resolution sonar for identifying the details of the sea floor and underwater objects. 
Cameras, line scanners, magnetometers, sub-bottom profilers, and numerous types of 
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oceanographic sensors have been developed to further man’s reach into and 
understanding of the marine environment. 

A key element of man’s operations in the marine environment has been the 
human element itself, which has been a bit of the proverbial “double edged sword”. On 
the negative side are such liabilities as the costs of salaries, benefits, and training; the 
costs and logistics of protection from the elements and of life support; time lost to rest 
and recreation; and the consequences of injury or loss of life. As is the case in such 
endeavors as space exploration, protecting and supporting human life entails significant 
increases in the size, complexity, and expense of equipment; reduction of mission 
duration; and added risk. The positive side of the human element is its unmatched 
versatility for perfonning a variety of tasks, for which there has long been no substitute in 
the complex marine environment. Additionally, unexpected situations frequently occur 
requiring human intervention, as human intelligence and reasoning are unequalled for 
making the appropriate decision in dealing with the new situation. Although removing 
humans from such operations is highly desirable from a liability standpoint, doing so has 
been challenging. Automation has advanced the process of removing the human element 
over time, starting with the simplest tasks. Many more complex tasks are yet to be 
successfully automated. The human element enhances operations in the marine 
environment, albeit at a price. A desirable goal would be to remove the human element 
while preserving the effectiveness inherent in it. 

AUVs remove the human element almost completely; more so than in related 
unmanned aerial, land, space, and sea surface vehicles. Communications methods 
available to these other vehicles provide ample opportunity for human participation and 
intervention during the course of a mission. AUVs are significantly constrained in their 
ability to communicate with external operators, and are therefore highly dependent on 
autonomous operation. The nature of their operating environment motivates much 
progress in the field of autonomy. 

B. HISTORY 

Development of AUVs has progressed in stages over the last few centuries. As is 
frequently the case, military operations provided significant motivation to develop and 
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advance technology. As in the above discussion, military effectiveness also benefits from 
inclusion of the human element. And, as above, the desire to minimize the cost and risk 
of human involvement motivates developments in automation. One typical military 
objective throughout history has been to deliver an effective explosive charge to the 
desired target with the objective of destroying it. Over time, automation has gradually 
replaced human methods of delivering the charge to the desired target. In 1585, during 
the siege of Antwerp by the Spanish Annada, defenders of the city sent an unmanned 
vessel filled with explosives and fused with a timer down the river Scheldt. It succeeded 
in its mission, which was to blast an opening into a barricade built across the river. The 
automation required was minimal, as the river’s ha nk s constrained the vessel’s path to 
arrive at the barricade, its flow brought it to the barricade, and the timer needed only 
delay the explosion until after the vessel was swept against the barricade (Gray, 1991). 

The more challenging and useful situation involved delivering the explosive 
payload below the waterline of a moving target in open water. The spar torpedo, placed 
on the end of a long pole at the bow of a small manned vehicle, represented an early 
solution. This involved a human element, which guided the vessel and its attached 
explosive payload to the intended target. The human cost and risk was to be mitigated by 
the distance provided by the length of the spar, or by the length of a rope that was pulled 
taut to detonate the torpedo after it was implanted in the target and the delivery vehicle 
backed away. As was demonstrated by the CSS Hunley’s sinking of the USS Housatonic 
during the Civil War, the weapon with it’s human controls was very effective; but the 
loss of the Hunley also demonstrated that the cost was too high and that further 
automation of the concept was necessary (Bak, 1999). The desire to achieve the same 
level of effectiveness, but at lower cost, resulted in development of possibly the first 
AUV, the Whitehead torpedo. It was developed by Robert Whitehead during the latter 
part of the 19 th century and further removed the human element. In fact, once launched, 
there was no human element. Whitehead overcame significant technical challenges in 
designing a suitable propulsion and control system for his torpedo. Propulsion was 
provided by a variety of different engines, and control was provided by a combination of 
gyroscope-based heading control and depth-cell based depth control (Gray, 1991). 


3 



Current torpedoes and AUVs are improvements on Whitehead’s invention. His 
propulsion designs were succeeded by internal combustion engines or electric drive 
powered by various types of batteries. His straight-running torpedo carried no sensors, 
other than an exploder to detonate the warhead when it sensed contact with a solid object. 
However follow-on torpedoes carried equipment such as wake or acoustic sensors to 
detect, track, and home on targets; as well as magnetic and other sensors to sense the 
proximity of a target and detonate the warhead at the appropriate time. Additionally, 
enabling a torpedo to process its sensor data to home in on a target required the addition 
of computational capability, first analog, then digital (Naval Undersea Warfare Center, 
1998). Military necessity brought a high level of autonomy and technical sophistication 
to underwater vehicles. 

Torpedoes represent one path of development towards AUVs, another was 
progress in sensor technology. Beginning with lead line soundings taken by dropping a 
tethered weight to the bottom to detennine water depth, a variety of tethered 
measurement devices and sensors have been used in the ocean environment. These 
include oceanographic instruments and camera sleds. The device was lowered to the 
desired depth at the desired location to take the measurement or image, then brought back 
to the deploying vessel where the data was downloaded from the device (McConnell, 
1982). This method of gathering data did not allow access to the data until the device 
was removed from the area to be sensed and back on deck. This not only delayed 
presentation of the data to the human operator, it prevented adaptive planning of the data 
gathering operation based on conditions sensed by the device (Andrews, 2004). 
Improvement came with tethers which also contained communication channels, such as 
wiring or optical fiber. Access to sensed data was available instantaneously, and the 
device could be repositioned in response to the sensed data to adaptively plan the data 
gathering operation and improve the usefulness of gathered data. The feedback provided 
by the communications link made control of the tethered device possible, and gave rise in 
the 1950’s to remotely operated vehicles (ROV) (Marine Technology Society, 2003). An 
ROV is typically outfitted with thrusters, control surfaces, and other equipment such that 
a human operator can drive the ROV by remote control in the performance of its mission. 
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This link to a human element allows ROVs to perform complex undersea missions 
without the actual presence of the human, eliminating the need for human requirements 
such as life support and protection at depth. Instead, the human element is located at a 
safe distance, either on a support vessel or at a networked location thousands of miles 
away. Additionally, the electrical connection to the surface vessel provides essentially 
unlimited power to the device 

Versatile as ROVs are, there are still limitations to be overcome. The requirement 
for a tether and support vessel limits the operations of the ROV to the length of the tether, 
and the speed at which the tether can be towed. Additionally, the necessity of the surface 
vessel limits ROV operations to areas accessible to the surface vessel, something which 
may be constrained by sea conditions, hydrography, ice, hostile action, or the desire to 
remain covert. Also, there is the expense of a continuously present support vessel. 

AUVs represent a follow-on development in both sequences of technological 
progress. They build on the fusion of propulsion, control, and guidance/logic technology 
developed to improve torpedo capabilities, and they are used as platforms to carry the 
sensors that have been tethered to other vessels. In doing so, those sensors may be 
employed more effectively than by tethered or other means. 

C. AUV APPLICATIONS 

Many applications for AUVs have been realized or are under development. Naval 
missions include deep-ocean search (Urich, 1995), mine countermeasures (Wernli, 1997), 
oceanographic measurement (Peterson and Head, 2002), intelligence, surveillance, 
reconnaissance, anti-submarine warfare and various support missions (Department of the 
Navy, 2000). 

An example of an economic application is the Hugins AUV, which has been used 
extensively and effectively for offshore petroleum exploration. It carries a variety of 
sensors to the vicinity of the ocean floor, a task previously performed by a sensor towed 
by a surface vehicle. By overcoming the speed and maneuvering limitations associated 
with the towed deployment scheme, survey time is reduced by over 50% (Chance, 2001). 
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AUVs are used extensively to gather oceanographic data, bringing methods of 
measurement previously not possible. They have been deployed under ice (Jones, 2002), 
where surface vessels could not operate, gathering data faster than would have been 
possible by boring through the ice from above and lowering instruments to take 
measurements. Long-duration AUVs such as gliders have remained at sea and gathered 
oceanographic data for extended periods of time without the need for a support vessel, 
and have demonstrated the ability to operate from an undersea dock, periodically leaving 
to gather data and returning to download data and recharge batteries (Curtin and 
Bellingham, 2001). 

D. AUV LIMITATIONS 

AUVs, however, are by no means a panacea. For all their advantages, there are 
areas in which they are inferior to tethered vehicles. One consequence removing the 
tether is that power is limited to what can be carried onboard. This limitation was the 
motivation for the development of nuclear power on manned submarines, and this same 
limitation on smaller, unmanned AUVs that has spurred development of advanced battery 
and fuel cell technology. Untethered vehicles also allow little or no human involvement 
in their mission, due to the limited communications bandwidth available. As a result, the 
complexity of their missions is limited by the degree to which they can be automated. 
Overcoming this limitation motivates further research in autonomy and underwater 
communications. A related consequence of this limited communications bandwidth is 
limited access by the operator to data gathered by the AUV. The most common method 
of retrieving the data gathered by the AUV is to recover the vehicle at the end of its 
mission and download the data via a computer network connection. In time-critical 
operations the resulting time delay may be unacceptable. Other methods, such as low- 
bandwidth acoustic communications or periodic radio communications periods on the 
surface, are also available but may not be operationally desirable. If covertness is a 
requirement for the operation, one reason for using an AUV instead of a vehicle tethered 
to a surface vessel, such methods of transmitting data may compromise covertness. 
Methods of transferring data covertly and at high bandwidth exist, such as optical 
(Lacovara, 2003) or high frequency acoustic modem exist (Kojima, 2002), but are of 
limited range (Etter, 1996). 
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E. SCOPE OF THIS WORK 

This work develops a high data rate method of covertly gaining access to data 
gathered by AUVs. Such autonomous, networked, accelerated access to data is in 
accordance with current Chief of Naval Operations guidance (Clark, 2002). This work 
implements the server vehicle concept proposed by (Marco and Healey, 2000) as a means 
of retrieving data from data-gathering vehicles to make it available to the operator while 
the survey is in progress. This method uses no radio transmissions, and limits other 
transmissions to either short-duration long-range acoustic or short-range acoustic or 
optical transmissions. Covertness is enhanced by this minimization of detectable 
transmissions. 

The approach for accomplishing this objective is autonomous AUV rendezvous, 
in which an AUV designated as a server vehicle is tasked to download data from a 
vehicle equipped with sensors which is gathering data on a survey, surveillance, or 
similar mission. After obtaining the data, the server vehicle delivers it to a node where it 
can be transmitted to the operator. The operation comprises a network of cooperating 
vehicles, with a single server vehicle servicing one or more sensor vehicles. 

Such a cooperative vehicle network of cannot adhere rigidly to a pre-scripted 
sequence of operations, as the unpredictable nature of sensed data, navigational errors, 
disturbances, and operational details make a priori knowledge of all necessary mission 
planning parameters impossible. As a result, rendezvous planning must be adaptive 
enough to bring the server vehicle to within short-range communications range of the 
sensor vehicle regardless of these unpredictable mission parameters. Additionally, 
because the adaptive planning must occur during the operation and after final interaction 
with the human element, the planning process must be autonomous. This builds on work 
by (Marr, 2003), wherein individual parameters in the AUV’s mission were transmitted 
by acoustic command and changed inside the vehicle. In this work, a set of parameters 
describing the location of the sensor vehicle are transmitted to the server vehicle, which 
uses the parameters to generate a new mission for itself and then executes the mission. 

Finally, the rendezvous process should be optimized in order to satisfy the 

objectives of the operation. Because the objective of the rendezvous concept is to 
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accelerate access to AUV data, it may be desirable to plan each rendezvous such that it is 
completed in as short a time as possible. Solutions to this time-optimal problem will be 
shown to require closing the rendezvous point at high speed, a mode of operation which 
quickly depletes the limited energy capacity of an AUV and therefore shortens its time on 
station. Recognizing the energy limitations of AUVs, it may be desirable instead to 
perform each rendezvous using the minimum possible energy. These energy-optimal 
solutions provide reasonable access times to AUV data and maximize server vehicle time 
on station. Other optimization objectives may also be desirable. This work addresses the 
above two optimization objectives, finding analytical/numerical solutions to both and 
implementing practical and efficient optimization of the rendezvous solution. 

This work made use of the Naval Postgraduate School Acoustic Radio Interactive 
Exploratory Server (ARIES) AUV. The unique behaviors necessary for AUV 
rendezvous; including dynamic mission planning, mission reconfiguration, command and 
control communications, and a new higher layer of operational control; were 
implemented in this AUV. 
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II. RENDEZVOUS 


A. SPACE RENDEZVOUS 

Decades before the space age the orbital rendezvous problem was being 
considered, with a focus on effecting rendezvous to meet specified optimization 
objectives. Hohmann (1925) first solved the problem of transferring a space vehicle from 
one orbit to another while expending a minimum of energy. The realization of space 
operations in the mid twentieth century motivated extensive work in optimal space 
rendezvous (Marec, 1979). In fact, the vast majority of the literature on the topic of 
optimal rendezvous pertains to space vehicles. 

Optimization objectives of space maneuvers include the minimum energy and 
minimum time, as will be considered here, however the physics of the space environment 
are radically different. The space environment is characterized by gravity, centripetal, 
and limited-duration thrust forces; whereas the AUV operating environment is 
dominated by drag, control surface, and near-continuous thrust forces. As a result, 
optimal rendezvous solutions for spacecraft have little utility for AUVs. 

B. RENDEZVOUS AND INTERCEPT 

Of greater relevance is the extensive work done with endo-atmospheric missiles 
and underwater vehicles. This is true because these tend to be finned vehicles operating 
under the influences of thrust and drag, as are AUVs. However, most of the literature for 
these vehicles involves intercept vice rendezvous. Figure 1 illustrates the difference. 
Designating the vehicle which maneuvers as the “chaser vehicle” and the second vehicle 
as the “target vehicle”, the objective of intercept is for the chaser vehicle to match the 
position of the target vehicle at some future point in time along the target vehicle’s track. 
Intercept is a momentary condition satisfactory for most weapons systems requirements 
that are the motivation of much of the research on the topic. In such cases a warhead is 
detonated near the point of intercept and no further maneuvering is necessary. In fact, 
warhead detonation generally makes further chaser vehicle maneuvers impossible as the 
chaser vehicle is destroyed. Rendezvous extends the concept of intercept, also matching 
vehicle positions but adding the requirement of matching velocity as well. As a result, 
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there is little if any relative velocity between vehicles and the vehicles remain in close 
proximity for an extended period of time. 



a. Intercept 

Position Matched 
Momentarily 


b. Rendezvous 

Position and Velocity Matched 
Sustained 


Figure 1. Intercept (a) and Rendezvous (b) 

C. COMPARISON OF INTERCEPT GUIDANCE LAWS 

Intercept is a useful step towards rendezvous since an intercept trajectory differs 
from a rendezvous trajectory primarily in the relatively short time period just prior to the 
rendezvous. For the remainder of the trajectory, which comprises the majority of the 
trajectory, intercept principles are of great utility. Many guidance laws have been 
developed for one vehicle to efficiently intercept a target vehicle, and two that represent 
the two fundamental approaches are known as pursuit and proportional navigation. 
These are shown in Fig. 2. 
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Target Vehicle 


N 



a. Pursuit 

Target Relative Bearing Nulled 
Chaser Points Target 
- All Speed in Line of Sight 



b. Proportional Navigation 
Bearing Rate Nulled 
Speeds Across Line of Sight Matched 
Remaining Speed in Line of Sight 


Figure 2. Pursuit (a) and Proportional Navigation (b) 


The pursuit guidance law acts to null the target vehicle’s bearing relative to the 
centerline of the chaser vehicle. By doing so the chaser vehicle always points the target, 
and all its forward speed u c is applied in the line of sight to maximize range rate at any 

given time. For a stationary target in Euclidean space this law provides the time-optimal 
intercept trajectory as the chaser vehicle is driven along the shortest possible path to the 
target. It is a simple law to implement since the chaser vehicle need only maneuver to 
keep the target’s image in the center of its homing sensor. 

Proportional navigation is probably the most studied and utilized of the missile 
guidance laws (Zarchan 2002). It intercepts the target by nulling the target’s bearing rate, 
generating the “constant bearing, decreasing range” condition that leads to collision 
between moving vehicles. Proportional navigation apportions the chaser vehicle’s 
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forward speed u c along two orthogonal axes. Chaser vehicle course is adjusted such that 
its speed across the line of sight, u c , matches target speed across the line of sight u t . 

Doing so puts the target vehicle in a position of having no lateral velocity relative to the 
target vehicle. The remainder ofw c , the speed in the line of sight u c , is then applied in 

the direction of the target in order to close to intercept. For the case of a stationary target 
this yields the same solution as pursuit guidance. 

Since its speed is always directed at the target, pursuit might seem to be the time- 
optimal guidance law. However, Fig. 3 illustrates why this is usually not the case. 
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Figure 3. Pursuit and Proportional Navigation of a 5.5 Meter Per Second Chaser Vehicle 

Intercepting a 6 Meter Per Second Target Vehicle 


A constant-velocity target vehicle moving at 6 meters per second on a constant 
southeasterly course and speed is to be intercepted by a chaser vehicle moving at 5.5 
meters per second. The chaser vehicle departs the origin, once using pursuit guidance 
and once using proportional navigation, and the positions of both vehicles are shown at 1 
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second intervals for a total of 50 seconds. The pursuit guidance law initially closes range 
more rapidly, but does not follow a direct path to the intercept point. Instead, because of 
the mismatch in speeds across the line of sight, the target vehicle changes bearing and 
presents a more opening aspect throughout the problem. The chaser vehicle falls into a 
“tail chase” with the target vehicle and closure rate drops significantly. In fact, because 
the chaser vehicle is slower than the target vehicle, range between vehicles eventually 
begins to open and the opportunity to intercept is lost. Compare this to proportional 
navigation, which in this case allows the chaser to intercept the target vehicle even 
though it is at a speed disadvantage. Note also that proportional navigation follows a 
straight-line path to the intercept point, wasting no path length enroute. In fact, 
proportional navigation has been shown to be the time optimal method for intercepting 
constant-velocity targets (Mehrandezh, Sela, Fenton, and Benhabib, 1999). 

Figure 4 illustrates the relative merits of these two guidance laws for the next 
level of complexity, the realistic case of a constant-speed maneuvering target. 
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Figure 4. Comparing Proportional Navigation and Pursuit Guidance, Maneuvering Constant 

Speed Target (After: Hutchins and Roque, 1995) 
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Here a 1 meter per second target vehicle follows a typical AUV survey pattern composed 
of parallel tracks. A chaser vehicle departs the origin as before, using each of the 
guidance laws. The chaser vehicle’s speed is 1.2 meters per second, and vehicle 
positions for 480 seconds are shown. In this case proportional navigation clearly results 
in excessive path length as the chaser vehicle tracks the target vehicle’s maneuvers. 
Unlike the previous example, pursuit guidance is now superior to proportional navigation 
in that interception occurs sooner. However, pursuit guidance is not optimal, as a direct 
path to the same rendezvous point and rendezvous time would have required the chaser 
vehicle to travel at only 1.0 meters per second thereby saving 42% of the propulsion 
energy required to reach the intercept point. Conversely, had the chaser vehicle traveled a 
direct route at 1.2 meters per second to intercept the target vehicle, it would have 
intercepted it in 421 seconds, a 12% time savings. Planning this direct path, however, 
requires a priori knowledge of target maneuvers. 

Rendezvous can be seen as an extension of the above discussion, provided that 
trajectory planning take into account the final course and speed changes required to 
match target vehicle velocity as well as position. 

Trajectory planning benefits from a priori knowledge of target vehicle 
movements. This is not a valid assumption for much of the previous intercept work, 
since this work stems from weapons research and therefore the target can be expected to 
attempt to evade the incoming interceptor. However, in the context of AUV rendezvous, 
a cooperative behavior between vehicles, it would be a reasonable assumption that the 
chaser vehicle could be provided the details of the chaser vehicle’s mission prior to the 
start of the operation. This assumption will be used in the rest of this work to optimize 
the rendezvous process. 
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III. TIME-OPTIMAL RENDEZVOUS 


A. OPTIMAL CONTROL FUNDAMENTALS 

Optimal control problems involve finding the sequence of control inputs to drive a 
system from a prescribed initial state to a prescribed final state while minimizing a 
specified performance index J(x). Denoting the set of control inputs as the vector u, and 
the states by the vector x, the general form of the perfonnance index is 

ff 

J(x,x\,t f ) = (j){t f ) + J L(x,u,t)dt (3.1) 

o 

The term (f)(t f ) is some specified function of the final state, and the integral term is a 
function of states and controls throughout the time period in question. 

The four necessary conditions for optimality, derived using the calculus of 
variations, are satisfaction of boundary conditions; plus 


dH . 

-= X 

dp 

(3.2) 

dH 

aT~ p 

(3.3) 

du 

(3.4) 


Where the Hamiltonian H, defined as 

H = L + p*x (3.5) 

is a convenient grouping of terms resulting from the derivation of the above conditions. 
It consists of the integrand of the performance index, plus the inner product of the costate 
vector p and the time derivative of the state vector (Bryson, 1999). 

The above assume that the magnitude of control inputs is unconstrained. 
However, in practical systems the magnitudes of control inputs are necessarily 
constrained, which can complicate solution of optimal control problems. Frequently the 
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optimal control solution obtained using the above equations requires infinite control 
effort. For example, the time-optimal problem of finding the force to be applied to a 
mass to accelerate it to a specified speed in the minimum possible time has as its solution 
an infinite force over an infinitesimal time period, the integral of which equals the 
impulse required to change the momentum of the mass the specified amount. Realistic 
systems with constraints on controls were addressed by (Pontryagin, 1962), who 
introduced the minimum principle as a generalization of Eq. 3.3 to specify that the 
optimal control minimizes the Hamiltonian at each instant of time, or 

u = argmin(Ef) (3.6) 

The rendezvous problem clearly falls into the category of constrained controls, 
owing to the finite control effort available to an AUV’s thrusters and control surfaces. 

The rendezvous problem also falls into the category of optimal control problems 
with constraints on the final state. Because the objective of rendezvous is for a chaser 
vehicle to match the position and velocity of a target AUV, the state of the target vehicle 
represents the specified final state of the chaser vehicle. 

The final state is not fixed, since the target vehicle is in motion. Instead there is a 
“target set” of states as a function of time. Additionally, because the final time for the 
problem is yet to be determined, this problem is also classified as one having an open 
final time. 

Finally, the rendezvous problem will be shown to have a singular solution. 

B. THE AUV EQUATIONS OF MOTION 

The equations of motion for the ARIES AUV describe its three-dimensional 
dynamics and kinematics. The pertinent aspects of AUV rendezvous involve motions in 
the horizontal plane, since vertical distances between vehicles, typically a few meters, are 
insignificant when compared to horizontal distances measured in hundreds or thousands 
meters. Because distance between vehicles is dominated by horizontal plane motion, and 
because there is insignificant cross-coupling between ARIES horizontal and vertical 
plane motions, only the horizontal plane is addressed in this work. The horizontal plane 
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motions of interest are steering, as controlled by the vehicle’s rudders, and surge, as 
controlled by the vehicle’s thrusters. 

1. Steering Equations 

The linearized equations of motion for steering (Healey, 1995) are of the form: 

Mx = Ax + Bu (3.7) 

Where M is the mass matrix, A is the dynamics matrix, and B is the control distribution 
matrix. Premultiplying both sides by M _1 results in the set of equations for x in the 
standard state-space form needed to solve the optimal control problem. The ARIES 
equations, assuming constant forward velocity u and using values determined by 
(Johnson, 2001) are: 

-0.149 0.890 0¥vl [ 0.153" 

-0.051 -0.411 0 r + -0.165 8 r (3.8) 

0 1 oJL^J [_ o 

The states are v, r, and y /, where v is sideslip velocity in meters per second, r is yaw rate 
or time derivative of vehicle heading in radians per second, and y/ is the vehicle heading. 
The control, 8 r , is rudder angle in radians. 

2. Simplification of the Steering Equations 

In order to examine the optimal control problem in a tractable form, the steering 
equations were simplified to a single equation. Of the three state variables in the steering 
equations, the vehicle heading i// is the most significant in determining vehicle motion. 
Sideslip velocity v is small compared to vehicle forward velocity u. Additionally, yaw 
rate r is the time derivative of heading angle y /. It does not significantly affect other 
vehicle motions, and its effects are accounted for in yr . 

Assuming that r reaches steady state early in a turn, a reasonable assumption 
based on ARIES operational data, the steady state version of second equation in Eq. 3.8 
becomes 

0 = -0.05 lv - 0.41 lr-0.165(5) (3.9) 
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Operational experience shows that the magnitude of v is generally less than the 
magnitude of r during a turn. This, coupled with the magnitudes of the coefficients in the 
first two tenns on the right hand side of Eq. 3.8, makes the first term over an order of 
magnitude smaller than the second term. Disregarding the v term and rearranging the 
above equation yields a simplified version of equation (3.7) 

iff = r = k x 8 r (3.10) 

The result is that, for constant speed, turn rate is proportional to rudder angle and the 
vehicle’s track in a turn is approximately a circular arc. This is a sufficiently accurate 
approximation for the optimal control solution that follows. 

Additionally, over ARIES operational speed range its turning radius is 
approximately constant. As a result, for a given rudder angle, its turn rate is 
approximately proportional to u, so for the optimal control solution, 

y/ = kuS r (3.11) 

3. Surge Equation 

The surge equation of motion describes the behavior of u in response to 
longitudinal forces acting on the vehicle, namely propulsive thrust and drag. Both are 
quadratic, with thrust proportional to the square of thruster speed N, and drag 
proportional to the square of u (Triantafyllou, 2002). Taking into account that ARIES 
always operates with a positive values of u and N, the simplified surge equation is 

u = aN 2 -j3u 2 (3.12) 

4. Kinematics 

The preceding equations of motion are augmented by kinematic relationships 
between the state variables to describe motion in the horizontal plane. The coordinate 
system used is the “North-East-Down” system where X is the northerly coordinate 
relative to some global origin, Y is the easterly coordinate, and Z is the downward 
coordinate, all in meters. Since ^orients the vehicle in the horizontal plane of this 
coordinate system, and vehicle velocity is predominantly in this direction (disregarding 
v), the simplified kinematic equations for the horizontal plane coordinates are 
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X = wcos^ 

Y = u sin \f/ 

Figure 5 illustrates these variables. The result is a set of four state equations 


(3.13) 

(3.14) 
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kuS r 
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UCOSff/ 

Y 


usini// 

u 


aN 2 -/3u 2 


(3.15) 


X 

(North) 



Figure 5. AUV State Variables 

5. Result 

The result of the above is the following set of expressions for the time optimal 
control problem. The objective is to find the sequence of control inputs, rudder 
commands 5fit) and thruster speed commands N(t), which minimize the time until 
rendezvous. The performance measure is simply 
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(3.16) 


j j 

J = tf = <P(t f ) + J L(x,u,t)dt = J1 dt 


and the integrand in Eq. 3.1 is unity. The Hamiltonian for this problem is therefore 

H = 1 + p x ku8 r + p 2 ucosy/ + p 3 usmy/ + p 4 \jxN 2 = 0 (3.17) 


The Hamiltonian equals zero whenever the Hamiltonian is not an explicit function 
of time and the problem has an open final time (Kirk, 1970). Substituting the 
Hamiltonian into Eq 3.2 simply yields the state equations Eq. 3.8 again. Substituting 
into Eq. 3.3 yields the following differential equations for the costates 


Pi = 
Pi = 

P i ~ 

P4 = 


SH 

Sy/ 


u(p 2 sin y/ - p 3 cos y/) 


SH 

SX 

SH 

SY 

SH 

Su 


= 0 
= 0 

= ~P\kS r - p 2 cos y/ - p 3 sin y/ + 2 p 4 fiu 


(3.18) 


Clearly p 2 and p, are constants. Inserting these into the first equation and integrating 
yields 

t 

Pi = ^(p 2 nsiny/- p 3 ucosy/)dt = p 2 SY - p 3 AX + yy (3.19) 

o 


which shows that p x has a constant value along lines in the horizontal plane 
corresponding to 


-1 1 

f AT 3 

_1 


tan 


= tan 


IaxJ 


l Pu 


(3.20) 


where AT and AX denote the change in vehicle X and Y coordinates since the start of the 
problem. 
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C. TIME-OPTIMAL SOLUTION FOR CONSTANT SPEED 

As a step towards determining the time-optimal solution, we first examine the 
case of a constant speed vehicle transitioning from a prescribed initial state to a 
prescribed final state in the shortest possible time. For simplicity, the value of u is fixed 
at 1 meter per second and maximum magnitude of rudder control is fixed at 1 unit. With 
no speed dynamics included, the final equation in Eq, 3.15 and 3.18 are removed. Initial 
vehicle position is at the origin, and the rudder constant of proportionality k is left 
unspecified. The problem is illustrated in Fig. 6. 



Figure 6. Initial and Final Vehicle Positions 

The objective is move from the initial state to the final state in the shortest 
possible time. The turn radius p for a vehicle moving along a circular arc at speed u and 
yaw rate \j/ is 


u 

P = ~ 
¥ 


(3.21) 
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In the limit as the rudder constant of proportionality k approaches infinity; p approaches 
zero, yaw rate y/ approaches infinity and this problem devolves to finding the shortest 
transit between the two points. At fixed speed, the solution is the well known straight 
line connecting two points in Euclidean space. This trajectory requires a constant course 
between the two points between initial and final turns, which in turn requires a constant 
zero rudder command. The constrained controls in this example invoke Pontryagin’s 
minimum principle, which requires minimization of the Hamiltonian at each moment in 
time. The Hamiltonian for the constant speed case is 

H = \ + p l kS r + p 2 cosy/ + p^siru// (3.22) 

and minimization involves finding the control 8 r at each moment that minimizes H. The 
coefficient ofc5> ( ., namely pjc , is know as the “switching function” since minimizing H 
involves always switching 8 r to its maximum value opposite in sign to the switching 
function to make the value of the complete tenn p x k8 r as small as possible at every point 
in time. Such full application of available control is commonly referred to as “bang”. 

Clearly the straight-line solution is not possible if the rudder is not zeroed. 
Zeroing the rudder occurs if the value of the switching function is zero itself, such that 
rudder angle no longer directly affects the value of the Hamiltonian. Such a situation is 
referred to as “singular”, and occurs here for p x =0. As discussed previously, straight 
lines of constant p x exist in the plane, so the optimal control solution to this problem has 
the constants p x , p 2 , and p , set to values which result in p x =0 on the line between 

these two points. The solution is referred to as “bang-singular-bang”, a straight transit 
between two maximum rudder turns. 

Because the switching function equals zero on the singular arc, the control history 
for rudder commands cannot be determined as the sequence which minimizes the 
Hamiltonian. Other means must be employed, and one common method is to note that if 
the switching function is to equal zero for the non-zero duration of the singular arc, its 
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time derivatives must also equal zero during that period. From Eq. 3.18 the derivative of 
the rudder switching function is 

p x = p 2 smy/- p^cosy/ (3.23) 

Since the only variable on the right hand side is y /, it must remain constant if p x 
is to remain equal to zero such that p x remains constant and equal to zero. This implies 
constant^, which by Eq. 3.23 implies zero rudder during the singular arc, as would be 
expected. 

As the value of k is reduced to reasonable values, the turn radii increase to finite 
values and curved portions appear on the ends of the trajectory. However, the fonn of the 
solution is unchanged. The situation is illustrated in Fig. 7. The singular arc still exists 
in the middle of the trajectory, along a new line of p x =0 as determined by the problem 
boundary conditions. 



Figure 7. Time Optimal Trajectory, Constant Speed 
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This result is continued by work on Dubins sets in the field of optimal path 
planning (Shkel and Lumelsky, 2001). This work involves finding the shortest possible 
path between two points when each point has an associated heading, with a maximum 
limit imposed on path radius of curvature. These conditions equate to the boundary 
conditions and control constraints of the previous problem. The optimal path of shortest 
distance, in cases when the distance between the two points was large compared to the 
radius of curvature, is a trajectory consisting of a minimum-radius curve followed by a 
straight segment followed by a minimum radius curve. The Dubins result is shown in 
Fig. 8. 



Figure 8. Dubins Solution 

D. TIME-OPTIMAL SOLUTION FOR VARIABLE SPEED 

Having characterized the time-optimal rudder control, the problem is now 
generalized to include variable vehicle speed. The problem is illustrated in Fig. 9, where 
all four vehicle states apply and the vehicle goes from zero initial speed to a final speed 
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Figure 9. Initial and Final States, Variable Speed 

The variable-speed Hamiltonian is 

H = \+ u( p ] k8 r + p 2 cosy/ + p 2 smy/) + p 4 [aN 2 - ] (3.24) 

The Hamiltonian is now to be minimized by the action of two controls, the rudder angle 
8 r and thruster speed N. Note that since thruster speed is a squared term and the speed 
switch is p A , the Hamiltonian is minimized by maximizing thruster speed whenever 
p A <0 and by stopping thrusters when p A > 0. Initially, since u j =0 and H=0, p A must be 

less than zero and full thruster speed is ordered to set the vehicle in motion. As the 
vehicle begins to move and turn, the middle tenn responds as it did in the constant-speed 
case to minimize the Hamiltonian. The path is identical to the constant speed case. 

The speed switching function is p A , which starts negative. From Eq. 3.18, its 
dynamics are governed by 


25 



p 4 = -p x k8r - p 2 cos y/ — p 3 sin^ + 2 p 4 fiu 


(3.25) 


Since the Hamiltonian equals zero at all times, Eq. 3.22 shows that the sum of the first 
three terms on the right hand side are equal to 1. With p 4 < 0 initially, and u=0, the last 

tenn starts equal to zero and goes negative. As a result, p 4 starts negative and begins 
increasing. Were it to go positive it will stay positive. There are two possible outcomes. 
In the first, the last term goes negative fast enough that p 4 never goes positive. In this 

case full thruster speed is ordered continuously. In the second, p 4 eventually goes 
positive and zero thruster speed is therefore ordered to minimize the Hamiltonian. The 
latter case corresponds to the vehicle accelerating to as high a speed as possible to 
minimize transit speed, then decelerating to meet the tenninal constraint on speed, as 
would be expected in satisfying the boundary conditions of this problem. This speed 
control is “bang-bang”, full speed command followed by zero speed command. The 
former case would correspond to a case where transit time is minimized and target 
vehicle speed equals maximum chaser vehicle speed. 

E. SOLUTION FOR MOVING TARGET BY NUMERICAL METHOD 

The above results provide the general characteristics of the solution to the time- 
optimal control problem for a stationary target vehicle. Because of the general difficulty 
in obtaining solutions to optimal control problems, a numerical method was used to 
verify that the solution for the more general case of rendezvous with a moving target was 
the same. 

The analysis was done using the MATLAB FMINCON constrained optimizer. 
An initial state was defined for the vehicle, as was a target set of final states. Parameters 
to be optimized were rudder and thruster commands. Thruster and rudder commands 
were discretized into 50 steps each, for 100 total control inputs. One additional 
parameter to be detennined was the size of the time step, for a total of 101 parameters. 
The FMINCON optimizer then determined the values of these parameters which resulted 
in the smallest step size, hence the earliest rendezvous time, subject to the constraint that 
the final state of the vehicle matched target vehicle state. Each thruster and rudder 
command was optimized individually to arrive at the earliest possible time at which 
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vehicle states were matched. The chaser vehicle started at the origin on course North 
(^=0) and speed = 1.0 meters per second. The target vehicle started at (100,0) on a 
southeasterly course (i// =0.75 n ) at speed = 1.0 meters per second. Turn dynamics are 

¥ = S r (3.26) 

and surge dynamics are 

u = 0.08iV 2 -0.08 m 2 = 0.08(w 2 COffl - u 2 ) (3.27) 

where u com represents speed command expressed in meters per second vice thruster speed 
in RPM. Control constraints limited the magnitude of rudder angle limited to 0.4 radians 
and speed to a maximum of 1.5 meters per second. These provide chaser vehicle 
dynamics similar to ARIES. 

The problem and results are shown in Fig. 10 through 12. 



Figure 10. Vehicle Tracks, MATLAB FMINCON Time-Optimal Rendezvous Solution 
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Figure 11. Control Flistories, MATLAB FMINCON Time-Optimal Rendezvous Solution 
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Figure 12. Speed and Heading, MATLAB FMINCON Time-Optimal Rendezvous Solution 
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Figure 11 shows the control histories for this problem. As discussed previously, 
rudder control was “bang-singular-bang”, with maximum-effort initial and final turns 
separated by a singular arc where rudder is essentially zero except for fluctuations due to 
the singular nature of this part of the problem. Except for one point affected by 
discretization error, speed control was “bang-bang”. The chaser vehicle accelerated to 
maximum speed and maintained maximum speed as long as possible, shortening the time 
until rendezvous. At the speed switch zero speed was ordered, decelerating the vehicle at 
the maximum possible rate such that vehicle speed, course and position were matched 
simultaneously. 

F. EXISTENCE AND UNIQUENESS OF THE SOLUTION 

Existence and uniqueness of the time-optimal solution can be addressed by 
considering two sets of vehicle states. The set of all possible chaser vehicle states begins 
as a single point in its state space, its initial condition, and grows as a function of time 
according to the vehicle’s control history during the time interval. This “set of reachable 
states” (Kirk, 1970), is defined for each future point in time. The target vehicle also has a 
set of reachable states, but if we assume that it follows a pre-specified trajectory without 
error its set of reachable states at any time is simply the point it is scheduled to occupy at 
that time. Figure 13 illustrates this, showing the initial and possible future positions of 
both vehicles at future points in time, position being a subspace of the state space. 
Clearly no rendezvous is possible if the target’s state is not a point in the chaser vehicle’s 
set of reachable states. The time at which the target vehicle’s future position is first 
included in the chaser vehicle’s set of reachable positions is the first candidate for time- 
optimal rendezvous, although all other states must be matched as well if rendezvous is to 
be feasible. The envelope of chaser vehicle reachable positions is defined by its 
maximum travel from its initial position by that time, which is detennined primarily by 
its maximum speed. Generalizing this to include all states, the earliest time for which the 
target vehicle’s state is included in the chaser vehicle’s set of reachable states is the 
earliest time that rendezvous is possible. This defines the time-optimal rendezvous 
solution. 
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Assuming the chaser vehicle has a speed advantage over the target vehicle, the 
solution exists. For no solution to exist the target vehicle must remain outside the chaser 
vehicle’s set of reachable states for all times, which occurs only if its speed exceeds the 
chaser vehicle, thereby keeping it outside of the chaser vehicle’s ever-expanding set of 
reachable states. The assumption of speed advantage is logical. If chaser vehicle speed 
did not at least equal target speed, it could not match speed with the target and therefore 
could not rendezvous with it. 

If the solution exists, it is unique. This is so because the target vehicle occupies 
exactly one position at any given time, and the time to rendezvous is a monotonically 
increasing function of target progress down track. Were multiple solutions to exists, each 
would be at a different position and time. Since the value of each time is unique, one 
would have a unique lower value than the others and would therefore be a unique time- 
optimal solution. 
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Initial Position 





Chaser Vehicle 
Set of Reachable Positions 
t=t, 



Chaser Vehicle 
Set of 
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Chaser Vehicle Initial Position 


Figure 13. Reachable Positions for Chaser and Target Vehicles 
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G. SUMMARY 

The results of this chapter indicate that the time optimal control history for AUV 
rudder is “bang-singular-bang”: a maximum-effort turn towards the rendezvous point, 
followed by a zero-rudder constant heading transit towards the rendezvous point, 
followed by another maximum-effort turn into rendezvous. Speed control is “bang- 
bang”: immediate maximum-effort acceleration to maximum speed, followed by a zero- 
propulsion maximum deceleration to match target speed at the rendezvous point. Control 
histories such as these can be implemented practically in the ARIES vehicle. 
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IV. ENERGY-OPTIMAL RENDEZVOUS 


A. OVERVIEW 

Along with situations requiring timely rendezvous are situations requiring energy- 
efficient rendezvous. Present AUVs are energy limited, with the vast majority powered 
by electric batteries. Propulsion is the largest demand on an AUV’s energy stores, a fact 
driving the development of long-duration glider vehicles. Propulsion demands on a 
server vehicle operating in a network of multiple sensor vehicles spread over a large area 
would be significant. In order to conserve server vehicle energy reserves, thereby 
extending its time on station, it would be advantageous to plan the rendezvous trajectory 
to be as energy-efficient as possible. This chapter detennines the characteristics of 
energy-optimal AUV rendezvous. 

B. AUV POWER CHARACTERISTIC 

The same approach as the previous chapter is used here, with the same necessary 
condition for optimality. The difference for energy optimality is the cost function, which 
here is the total energy required for rendezvous, defined as the integral of power over 
time. 

The AUV power characteristic is the sum of two terms: “hotel” loads and 
propulsion loads. Hotel loads are those which are approximately constant over time, such 
as power for computers and sensors. Propulsion loads are those required to power the 
vehicle’s main thrusters, and are proportional to the product of thrust and vehicle speed. 
Since thrust is approximately proportional to the square of thruster speed, and steady state 
vehicle speed is proportional to thruster speed (Triantafyllou and Hover, 2002), a 
reasonable relationship for vehicle power requirements is 

P = A + BN 2 u (4.1) 

where P is power in watts, A is hotel load in watts, B is the propulsion power coefficient, 
and u is present vehicle speed. N is thruster speed command expressed as steady-state 
vehicle speed in meters per second. In steady state this becomes 

P = A + BN i = A + Bu 3 (4.2) 
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To define the cost function for the ARIES vehicle, its values of A and B had to be 
determined. This was done by installing an electrical current sensor in its power circuitry 
and logging vehicle power requirements as a function of speed, including zero-speed 
measurements of hotel loads. The data is shown in Fig 14. 



Figure 14. ARIES Power Characteristic 

Fitting the parameters A and B to this data and substituting into Eq. 4.2 yields, for 
steady state operation 

P = 147.0 +179. lu 3 = 147.0 +179.1A 3 (4.3) 

C. USABLE SPEED RANGE 

Figure 14 shows that power measurements were taken for conditions of no 
propulsion and for propulsion in the upper end of ARIES’ speed range. The lack of data 
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between 0 and 0.7 meters per second is due to a practical limit on minimum speed for 
ARIES and many other AUVs. 

Low-speed operation is restricted by vehicle control considerations. Vehicles 
such as ARIES that use control surfaces vice thrusters to maintain attitude and depth 
require forward speed through the water to generate control surface forces. Below a 
minimum threshold speed vehicle control is lost, so operations are limited to speeds 
greater than this threshold. 

A more significant effect is the tendency to ballast AUVs to be positively 
buoyant, a practice that assures eventual return to the surface and vehicle recovery in 
nearly all circumstances. This is particularly desirable considering the cost and 
complexity of typical AUVs. Any deviation from neutral buoyancy introduces a buoyant 
force that must be overcome by forces generated by control surfaces, which is not 
possible below a certain threshold. 

Finally, surface suction forces exist which tend to keep the vehicle surfaced until 
sufficient control surface forces are generated to overcome suction and the vehicle is able 
to dive. This occurs both at the start of the vehicle’s run and whenever the vehicle 
returns to the surface to obtain a GPS fix. 


The result of the above is a constraint on energy-optimal solutions that vehicle 
speed be no less than the vehicle’s lowest controllable speed. Based on ARIES 
operational experience, this was established at 1 meter per second. 

D. MOST EFFICIENT SPEED 

A key aspect of finding the energy-optimal rendezvous trajectory is to identify the 
most efficient speed. A common definition of most efficient speed is the speed for which 
the greatest distance is covered per unit energy expended. For vehicles having a power 
characteristic in the form of Eq. 4.1, the solution (Bongiomo, 1967) is 


u = 


A_ 

k 2Bj 


(4.4) 
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However, this is solution applies to transits of unspecified length or transit to a 
fixed end point, which in this context equates to rendezvous with a stationary target. For 
rendezvous with a moving target it is necessary to generalize the solution. 

The energy optimal rendezvous with a moving AUV must take into account the 
effect of the target’s movement on energy requirements. Figure 15 shows the initial 
positions of ARIES and a target vehicle, as well as the future positions of the target 
vehicle as a function of time. 


Target Future 
Positions 


t=13 


t=19 o 

l 


Target Initial 



Figure 15. Target Positions and Ranges as a Function of Time, With Decomposition of 

Target Velocity u t Into Components Across (u t ) and Into (u t ) the Line of Sight 


Each future target position is a candidate rendezvous point, with a candidate 
rendezvous time t r . Each future position has a range R associated with it, which is the 

distance from ARIES’ initial position to that point. Unlike the time-optimal case, where 

the optimal rendezvous point was simply the earliest point for which rendezvous is 
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possible, the location of energy-optimal rendezvous point is less obvious. Assuming that 
ARIES travels to the rendezvous point along a straight path at constant speed «(/,.), 
defined as 

«(0 = — ( 4 - 5 ) 

K 

Figure 15 shows that the value of u(t r ) for the earliest points will be extremely large, as 
the values of t r are small. Disregarding the curved ends of ARIES rendezvous trajectory 
for the moment, the energy E required to rendezvous at target’s position at time t r is 
equal to power times the time available to transit to that point, or 

E{t r ) = \A + Bu(t r ) 3 \ = d + t r = At r + B ( 4 . 6) 

V t r ) \ t r 


A necessary condition for the function E( t r ) to have a minimum is 

^(O- 0 - BR\t r ) [ 2 R(t r ) n dR(t r )' 
dt r tl t r dt r 

, 3 dR{t r ) 
dt r 



(4.7) 


One consequence of Eq. 4.7 is that the most efficient speed is a function of 
problem geometry. The final term in the equation is the target velocity component in the 
line of sight, or range rate. Compared to the case of a stationary target discussed 
previously, the most efficient speed for a target with a negative range rate or closing 
target will be lower, while the converse is true for an opening target. Note that, for zero 
range rate, Eq. 4.7 reduces to Eq. 4.4. 

A second consequence is that, for the earliest rendezvous opportunity (time 
optimal rendezvous), u{t r ) will have its maximum value and will drive Eq. 4.7 strongly 

negative, getting less negative with time as the value of u(t r ) decreases. The result is a 
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time period early in the problem during which the energy required for rendezvous 
generally decreases if rendezvous is delayed. 

A third consequence is that the minimum-energy point can exist at any time in the 
problem, complicating the process of finding it. The final tenn in Eq. 4.7 is determined 
by the target’s heading and speed, both of which can be programmed to change at any 
time. A change from opening to closing aspect, as occurs att r =3 in Fig. 15, will cause an 

immediate drop in the value of Eq. 4.7, which may signal the opportunity for a new 
minimum, possibly a value lower than previous minima depending on the length of the 
period of closure. As a result, the energy-optimal rendezvous point is more difficult to 
locate; and the search for it more extensive than the time-optimal case. 

A related consequence is that minima tend to be located at points where the 
target’s aspect changes from closing to opening. This happens either when the target 
turns away, as occurs at t r =8 in Fig. 15, or for targets on straight paths as they reach the 

closest point of approach, as occurs at t r =19. 

A computer simulation depicted in Figs. 16 and 17 demonstrate the above points. 
Figure 16 shows ARIES initial position southeast of a target vehicle’s operating area. 
ARIES is to rendezvous with the vehicle, which is running a typical AUV survey pattern 
along parallel tracks defined by waypoints. The target’s speed is constant at 1 meter per 
second, and ARIES maximum speed is 1.5 meters per second. Figure 17 is a plot of 
energy to rendezvous as a function of rendezvous time. For each candidate rendezvous 
point, the energy to rendezvous is calculated using Eq. 4.6. Since the curve is only 
plotted for points reachable by ARIES at 1.5 meter per second or less, most of the points 
prior to t=500 seconds are not plotted. Early on, energy requirements for the first few 
points drop with increasing time as discussed above. The curve is highly non-linear, 
having several maxima and minima caused by target maneuvers, changes in target aspect, 
and the passage of time. The curve shows that, as the target maneuvers from closing to 
opening aspect at way point 2, energy required to rendezvous begins to increase, with the 
opposite occurring as it maneuvers to a closing aspect at way points 3 and 4. 


38 



Meters North 



Meters East 


Figure 16. ARIES Rendezvous With Maneuvering Target, Waypoints Annotated 


x 10 5 



Figure 17. 


Energy to Rendezvous, as a Function of Time, With Way Points Annotated 

39 

































Also plotted on Fig. 17 are two limits for minimum possible energy. The upper 
line is ARIES minimum possible energy expenditure assuming that it must maintain u 
greater than a minimum controllable speed of 1 meter per second. In this case the lowest 
power state of the vehicle corresponds to loiter or transit at 1 meter per second. The 
lower line is the minimum possible energy expenditure if there were no minimum 
controllable speed. This latter line represents a no-propulsion vehicle state, with only the 
hotel load. 

For the minimum loiter speed case, the energy-optimal rendezvous is defined by 
the point on the rendezvous energy curve to the left of the minimum energy for minimum 
loiter line that has the lowest energy value. For this case, the energy-optimal rendezvous 
occurs at way point 2. ARIES’ speed enroute to the rendezvous point in this case was 
1.223 meters per second. As discussed above, this is a case where a target maneuver 
from a closing to opening aspect causes a minimum on the energy curve. Analysis of this 
rendezvous point showed that it was the point satisfying Eq. 4.7. Rendezvous is still 
possible for later times, such as way points 4 and later, but would involve ARIES 
loitering at 1 meter per second and using up unnecessary transit distance while waiting 
for the rendezvous at the later point. 

For the case of no minimum loiter speed, the energy-optimal rendezvous point is 
simply the global minimum. In this example, the point occurs between way points 4 and 
5, and ARIES speed enroute to rendezvous would have been 0.487 meters per second if 
there were no ARIES minimum speed. This is an example of the other case discussed 
above: a minimum occurring on a steady course, where the value of Eq. 4.7 passes 
through zero due to the gradual change in target vehicle aspect as it proceeds down track. 

Note that the target maneuver at way point 3 created a global minimum. Had the 
target not maneuvered and remained on its northerly course, the global minimum would 
have occurred at way point 2. This illustrates how the energy-optimal rendezvous point 
is highly dependent on the specifics of the target’s track, and the necessity of examining a 
large portion of its track to identify the energy-optimal rendezvous point. 


40 



Note also that for the minimum loiter speed case that the latest possible energy- 
optimal rendezvous is the first intersection of the energy curve with the minimum energy 
for minimum loiter line. This is so because the line has a positive slope, therefore any 
rendezvous after this intersection must involve a greater amount of energy. 

Finally, note that in this case of a constantly maneuvering target that its 
geographic position does not change quickly; it tends to remain in the same geographic 
area and proceed slowly to the east. As a result, the energy required to rendezvous 
quickly converges to the hotel load. 

E. CHARACTERISTICS OF THE ENERGY-OPTIMAL SOLUTION 

The preceding assumed ARIES trajectory to rendezvous was a straight line, 
disregarding the effects of initial and final course and speed changes necessary to 
complete an actual rendezvous trajectory as discussed in the previous chapter. The same 
methods used in the previous chapter are applied here to determine the characteristics of 
the energy-optimal rendezvous trajectory. What differentiates the two is the cost function 
J(x,u,t f ). 

Proceeding as with the time-optimal case, the cost function for the energy- 
optimal case is the total energy to rendezvous. The problem still features constraints on 
controls and final state, which is still defined as a target set since final time is still open. 
It will also be shown to be singular. 

The cost function is the integral of power over time, or 

f f < r 

J(x,u,t f ) = <j>(t f ) + J L(x,u,t)dt = ^A + BN 2 u^it (4.8) 

0 0 

Using this integrand to form the Hamiltonian yields 

H = ^A + BN 2 u~^ + p x n5r + p 2 ucosy/ + p^iismy/ + p 4 (aN 2 - flu 2 ) 

= (Bu + ap 4 )N 2 + p 1 udr + A + p 2 ucosi// + p 3 usiny/- p 4 fiu 2 (4.9) 

= 0 

The speed switching function is 
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(Bu + ap 4 ) 


( 4 . 10 ) 


Bongiono (1967) showed that speed control for a non-maneuvering vehicle was singular, 
and that its value was provided by Eq. 4.4, the most efficient speed for that case. It is 
also singular here as well, when Eq. 4.10 equals zero. This is expected since energy- 
optimal rendezvous should involve operation at speeds other than extremes. 
Substituting the Hamiltonian into the necessary conditions for optimality yields 


P\ = 
Pi = 
Pl = 
Pa ~ 


SH 
Si/r 


u(p 2 sin^- - p 2 cos^) 


SH 

SX 

SH 

SY 

SH 

Su 


= 0 
= 0 


= -BN 1 


p x kSr - p 2 cos y ~ Pi sin y/ + 2 p 4 /3u 


(4.11) 


Again, as in Ch. Ill, p 2 and p 3 are constants. And again, p x has a constant value along 
lines in the horizontal plane. So rudder control is “bang-singular-bang” in the energy- 
optimal case as well. Speed control is now “bang-singular-bang”, with N 2 driven to 
zero for positive values of the switching function, maximum for negative values of the 
switching function, and the most efficient speed when the switching function equals zero. 
F. NUMERICAL SOLUTION 

The same scenario run in Ch.III was run for the energy-optimal case. The results 
are shown in Figs. 18 through 20. Rudder and speed control are “bang-singular-bang”. 
Starting from an initial speed of 1.0 meters per second, the initial speed order is 
essentially zero for the first time step, decelerating the vehicle to 0.876 meters per 
second. Speed command is held there until the final time step before rendezvous, where 
it is increased to match target speed of 1.0 meters per second at rendezvous, which occurs 
at 88.76 seconds. 
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Figure 18. Vehicle Tracks, MATLAB FMINCON Solution to Energy-Optimal Rendezvous 
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Figure 19. Control Histories, MATLAB Solution to Energy-Optimal Rendezvous 
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Figure 20. Speed and Heading, MATLAB Solution to Energy-Optimal Rendezvous 


G. EXISTENCE AND UNIQUENESS OF THE SOLUTION 

As was the case in Ch. Ill, the rendezvous solution exists when the chaser vehicle 
has a speed advantage over the target. 

The solution is not necessarily unique, however. Considering Fig. 17, it is 
possible that target vehicle maneuvers could produce several identical energy minima. In 
such cases, considering the nature of rendezvous operations, it would be advantageous to 
select the earliest such minimum. This will be the approach taken for implementation in 
ARIES. 

H. SUMMARY 

Energy-optimal rendezvous involves “bang-singular-bang” control of both rudder 
and speed. The shape of the trajectory is similar to the time-optimal track, with 
maximum-rudder initial and final segments bracketing a straight singular section. A 
singular arc is also contained in the speed control history, where the speed commanded is 
the most efficient speed for the particular problem. 
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V. IMPLEMENTATION OF AUV RENDEZVOUS 


A. OVERVIEW 

The time optimal and energy optimal AUV rendezvous trajectories derived in Ch. 
Ill and IV were implemented in the NPS ARIES vehicle, a test bed for investigating new 
AUV capabilities and behaviors. Originally designed to serve as a communications node 
for a network of AUVs, it was well suited for this demonstration. 

The essential aspects of the optimal control solutions obtained in the previous 
chapters were adapted for implementation in ARIES, with modification to provide the 
necessary efficiency and robustness for this implementation. 

B. IMPLEMENTATION OF OPTIMAL CONTROLS 

The previously-derived optimal controls solutions can be summarized as a set of 
rules which a planning process must observe in order to approximate the optimal controls 
for AUV rendezvous. For time optimal rendezvous, the rules are: 

- Bang-bang speed control: Accelerate immediately to maximum speed, holding 
maximum speed as long as possible without overshooting the final rendezvous state, 
decelerate using minimum propulsive power to match target speed when both vehicles 
arrive simultaneously at the arrival point. 

- Bang-singular-bang rudder control: Immediately make an initial maximum- 
rudder turn to the closing course, maintain constant course (zero rudder) as long as 
possible without overshooting the final rendezvous state, then make a final maximum- 
rudder turn to rendezvous course, timed to match target course when both vehicle arrive 
simultaneously at the arrival point. 

For energy-optimal rendezvous the rules are: 

- Bang-singular-bang speed control: Immediately change speed to the most 
efficient speed for the scenario, hold this speed as long as possible without overshooting 
the final rendezvous state, then change speed to match target speed when both vehicles 
arrive simultaneously at the arrival point. 

- Bang-singular-bang rudder control: Same as time-optimal case. 
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These essential aspects of the optimal control solutions were implemented in the ARIES 
mission planning process. In order to avoid convergence problems and to conserve 
ARIES’ computational resources, the ARIES planning process was not written as a large- 
dimension parameter optimizer as was used in Ch. Ill and IV. Instead, these aspects of 
the optimal solutions formed a set of rules to be observed by a trajectory planning routine 
which applied them in searching for the minimum-time or minimum-energy rendezvous 
trajectory for the vehicle states at the time of planning. 

The previously-derived optimal controls represent typical solutions to such 
optimal control problems: determined by the initial state of the system, the parameters of 
the system, and perfect information about both. Such solutions are completely 
determined at the start of the problem. For a given system, the trajectory is determined 
by the initial conditions and no adjustment or feedback is required during the problem 
run, hence the “single sample” or “open-loop” description of such problems. The AUV 
optimal controls previously presented do not account for such real-world phenomena as 
imperfect target and chaser vehicle state information, such as courses, speeds, and 
positions. Nor do they account for unpredictable disturbances such as variations vehicle 
dynamics parameters or currents and weather. These effects cause the optimal control 
solution to degrade over time as errors propagate, disturbances affect the system, and 
updated infonnation becomes available. To counter these degradations, it is necessary to 
periodically re-evaluate the status of the rendezvous and to replan it based on updated 
information. 

C. CONCEPT OF OPERATIONS 

In order to proceed with development and implementation of the rendezvous 
behavior, it was first necessary to establish several planning assumptions to guide 
software development. They specify realistic constraints to be addressed in rendezvous 
software. 

1. Network Comprised of One Server and Multiple Sensor Vehicles 

One server vehicle acts as a central communications node for a network of sensor 
vehicles. It downloads data from these vehicles during rendezvous, and later uploads 
this data to the next communications node. The area of operations is divided into zones. 
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Each zone contains one sensor vehicle, carrying a sensor payload used to gather the 
desired data in this zone. Examples of such data include locations of threats such as 
mines or obstacles, or time-sensitive information on the activities of an opposing force. 

2. Server Vehicle Knowledge of Sensor Vehicle Mission 

Assuming the same operator controls all vehicles in the network, it is reasonable 
to assume that essential elements of the sensor vehicles’ mission can be made available to 
the server vehicle prior to the start of the operation. Such information includes positions 
of intended waypoints and vehicle speed along each mission leg. This is data that would 
not be expected to change during the operation, and providing such data to the server 
vehicle a priori reduces the amount of data that must be communicated between vehicles 
to plan a rendezvous. Other aspects of the mission, such as actual target vehicle position, 
might vary in response to effects such as currents and other uncertainties. As a result, 
some information must be exchanged between vehicles in order to rendezvous. 

3. Default Server Vehicle State = Loiter 

The server vehicle loiters in a specific location. When pursuing a rendezvous it 
departs the loiter area for the operating area of one or more sensor vehicles, and returns to 
the loiter area once all rendezvous are complete. This allows selecting a loiter area to 
optimize communications and transit paths between vehicles. 

4. Minimal, Dual-Mode Communications 

Covertness, as well as reducing network traffic, requires minimizing the volume 
of inter-vehicle communications. This is achieved through a dual-mode communications 
scheme. A command-and-control mode consisting of a long-range, high-reliability, low 
data rate mode is used for long-range communications between vehicles to request and 
coordinate the rendezvous process. The volume and length of these transmissions is 
minimized to improve covertness and to minimize network traffic. A rendezvous mode 
consisting of a short-range, high data rate mode is used during rendezvous to pass data 
from sensor to server vehicle. The short-range nature of this mode provides covertness. 

5. Rendezvous in Response to Sensor Vehicle Request 

The server vehicle will rendezvous with sensor vehicles in response to their 
requests, as opposed to rendezvous with sensor vehicles on a pre-determined schedule. 

Requests are transmitted by sensor vehicles when their logic indicates that a significant, 
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time-sensitive, reportable event has occurred. This scheme simplifies server vehicle 
operations in that it minimizes server vehicle movements, reducing total propulsion 
energy required. Also, if the loiter area optimizes communications, loitering in this area 
except when conducting rendezvous improves the likelihood that the vehicle will be in 
this location, thereby improving communications reliability. 

6. Vehicle Network Operates Asynchronously 

Because the server vehicle responds to rendezvous requests from sensor vehicles, 
which may request rendezvous at any time, the network necessarily is asynchronous. The 
handling of rendezvous requests in server vehicle software must ensure that requests are 
properly queued and that information contained in queued requests is updated when 
updates become available. 

7. Sensor Vehicle Does Not Maneuver for Rendezvous 

Sensor vehicles perform their missions throughout the operation of the vehicle 
network, including rendezvous for data transfer. The sensor vehicle does not deviate 
from its mission profile to facilitate the rendezvous. The server vehicle perfonns all 
rendezvous calculations and maneuvers to satisfy the rendezvous optimization objective. 
An important implication of this is that the sensor vehicle’s speed must not exceed the 
server vehicle’s speed at any time. Were this not true, the server vehicle would need to 
alter its operations by slowing down to pennit the server vehicle to rendezvous. A more 
general implication is that sensor vehicle dynamic characteristics must not exceed those 
of the server vehicle to a degree that rendezvous may be disrupted. The detailed dynamic 
limits would be dependent on the rendezvous communications method. An example 
would be a sensor vehicle whose turn rate so exceeds the server vehicle’s that rendezvous 
communications between vehicles is significantly disrupted. A directional optical 
method might impose stringent limitations on vehicle turn rates and other dynamics to 
ensure that the directional sending / receiving devices stay aligned during rendezvous. 
However a more omni-directional acoustic method might only require that vehicles 
remain within it’s maximum range capability during maneuvers, permitting divergent 
turn rates and courses so long as they do not result in exceeding this maximum range. In 
summary, we assume that vehicle dynamics are controlled such that they cannot disrupt a 
rendezvous in progress. 
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8. Vehicles Maintain Ground Track and Speed Through Water 

In the presence of currents, AUVs can be expected to be set away from their 
intended track over ground. The usual response to this effect is for the AUV to adjust its 
heading and assume a “crab angle” to counter the effect of currents. Ground track is 
maintained, although speed over ground may be affected. In this implementation, the 
rendezvous planning process assumes that vehicles subject to currents adjust their courses 
accordingly. However, they are assumed to maintain their pre-planned speed through the 
water while doing so, making no adjustment in speed for the effects of currents. This is 
reasonable since vehicles will frequently operate at a maximum or minimum attainable 
speed through the water, in which case no increase or decrease in speed may be possible. 

9. Optimality 

Rendezvous trajectories are to satisfy either a minimum energy or minimum time 
optimization objective. 

10. Robustness 

Software must be tolerant of real-world effects such as navigation inaccuracy, 
communications drop-outs or garbles, or ocean currents. 

D. ROBUSTNESS FEATURES 

The following features were incorporated into rendezvous management software. 

1. Rendezvous Queue Management 

The asynchronous nature of the network results in random arrival of rendezvous 
requests from sensor vehicles. Additionally, a request from one vehicle may arrive while 
the server vehicle is closing or engaged in rendezvous with another sensor vehicle. 
Requests are queued for action in order of arrival, with the first request completed in its 
entirety before the next request is acted upon. Also, since rendezvous requests convey 
sensor vehicle navigation data which may change significantly while the request is in the 
queue, sensor vehicles may send subsequent rendezvous requests containing updated 
navigation data. The queue is managed such that the updated request replaces the 

previous request for any sensor vehicle in the queue, rather than adding it to the queue as 
a new rendezvous request. If such a request is received from the sensor vehicle that the 
server vehicle is enroute to rendezvous with, receipt of the request triggers an immediate 
replanning of the rendezvous. 
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2. Missed Rendezvous Logic 

Once a rendezvous is planned, the rendezvous process must be able to overcome a 
failure of rendezvous communications at the rendezvous point. Action must be taken to 
correct the problem and, if uncorrected, the rendezvous must be tenninated so that the 
server vehicle can break out of this state and proceed with other aspects of its operation. 
This situation could be caused by a failure of communications equipment, incorrect 
rendezvous planning by the server vehicle, or by inaccurate navigation or equipment 
malfunction for either vehicle. In such instances, the server vehicle first queries the 
sensor vehicle to report its present navigation data so that another rendezvous can be 
planned. If no response to this query is received, the server vehicle abandons the 
rendezvous and deletes the rendezvous request from the queue. 

3. Rendezvous Request Check Sum 

One possible cause of the above missed rendezvous scenario is the possibility that 
garbled navigation data contained in the rendezvous request results in the incorrect 
planning of a rendezvous, with the server arriving at an erroneous rendezvous point. To 
prevent this occurrence, rendezvous requests contain check sums to improve the 
probability of correct receipt of rendezvous request navigation data. 

4. Mission Feasibility Check 

To guard against other unforeseen causes of incorrect rendezvous planning, the 
final results of the rendezvous mission generated by the mission planning process is 
checked for feasibility of waypoint positions. A navigational envelope is defined around 
the area of operations which contains all expected sensor vehicle positions during the 
operation. If any of the waypoints contained in the rendezvous mission generated 
onboard ARIES fall outside of this envelope the mission is deemed infeasible and is not 
acted upon unless a subsequent rendezvous request containing corrected sensor vehicle 
position data is received. 

5. Currents 

Because currents can significantly affect navigation accuracy, the rendezvous 
planning process accepts set (direction) and drift (magnitude) of currents as inputs and 
accounts for their effects on vehicle speeds and headings in planning rendezvous 
missions. 
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6. Navigation Accuracy 

Because ARIES fixes its position by surfacing for GPS fixes, it can only fix its 
position periodically, generally once every few minutes. The remained of the time it uses 
speed and heading sensors to dead reckon its position. Sensor errors lead to position 
errors that grow over time. Additionally, it is reasonable to expect that sensor vehicles 
are affected similarly, and will periodically update their reported positions. To account 
for these effects and update the rendezvous solution, rendezvous missions are 
periodically replanned while in progress. 

E. BASELINE ARIES CHARACTERISTICS 

The NPS ARIES vehicle is a shallow-water AUV used as a test-bed to explore 
new concepts for autonomous vehicles. As such, its hardware and software are 
frequently modified. The following description applies to its “baseline” or normal 
configuration, prior to modification for rendezvous operations. 

1. Hardware 

Key components are shown in Fig. 21. ARIES is powered by 6 lead-acid batteries 
which provide several hours worth of power. Propulsion is provided by two fixed stern- 
mounted thrusters and vehicle attitude is controlled by two bow planes, two stem planes 
and two top-mounted rudders. It navigates by fusing a variety of navigation sensors; 
including compasses, velocimeters, gyros, an inertial measurement unit, and a GPS 
receiver which provides fix infonnation whenever the GPS antenna is out of the water 
and exposed to the GPS satellite constellation. The present sensor configuration consists 
of a video camera and supporting storage, processing, and transmission equipment, 
although various sonar systems have also been carried. Because of its design as a 
communications node, ARIES carries both radio and acoustic communications 
equipment. For the implementation of AUV rendezvous the key piece of 
communications equipment was the Benthos acoustic modem, which has been used for 
previous communications research (Marr, 2002) and which enables communications 
between submerged vehicles. Its capabilities were adequate for command and control 
communications such as sending and receiving rendezvous requests and for reporting 
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Figure 21. ARIES Vehicle Diagram (After: Marco, 2001) 
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vehicle status. No hardware modification, other than addition of the electrical current 
sensor used to measure ARIES’ power characteristic function, was necessary. 

ARIES’ operation is controlled by a dual processor computer. Each processor 
consists of a Pentium 166MHz CPU on an EBX motherboard, each hosting various PC- 
104 input/output cards. Both processors run the QNX 4.23a real-time operating system. 
Communications between processors and to other computers is via a 10Base2 Ethernet 
connection. An additional connection to the processor designated QNXE is provided via 
FreeWave radio modem. This connection is used during ARIES operations when ARIES 
is not physically connected to an Ethernet cable, and permits command and control of the 
vehicle while it is on the surface. 

2. Software 

The baseline ARIES software architecture is as shown in Fig. 22. The primary 
function of the processor designated QNXT is navigation. It hosts several processes, 
most of which process data from navigation hardware. Associated with each process are 
shared memory blocks where processed data is written for reading by the Nav process. 
The Nav process uses an extended Kalman filter to fuse sensor data into accurate 
navigation data. QNXT also hosts processes for overlaying navigation data onto video 
images (Bob II), for digitizing analog signals from navigation equipment and other 
vehicle systems (Analog), and for transmitting navigation data to QNXE (QtS). 

QNXE controls vehicle mission execution. It receives the navigation data 
supplied by QNXT via the network process QeR and, using various sliding mode 
autopilots, sends commands to ARIES’ six control surfaces to maintain course and depth. 
The mission is described in the mission script file, which could contain a sequence of 
low-level commands such as thruster speeds, control surface angles, headings, depths, or 
altitudes to be executed. However, usual ARIES missions are described at a higher level. 
Rather than specifying the low-level details of the mission, the script file typically calls 
for a “waypoint control” mission. In this case, a second file which describes the mission 
as a series of navigation waypoints is read into the Exec process at the start of the 
mission. Each line of this file specifies the position of the next waypoint, as well as the 
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QNXE 1 QNXT 



Figure 22. ARIES Baseline Computer Software Architecture, Showing Processors, Network 
Connections, Processes, Shared Memory (SM) Structures, and Mission Definition 
Files. Boxed Region in QNXE Was Later Modified for Rendezvous as shown in 

Fig. 24 (After: Marco, 2001) 


speed, depth or altitude, time limit for arriving at the next waypoint, and how closely to 
approach the waypoint before activating the next waypoint. The details of the ARIES 
waypoint file are shown in Fig. 23. 
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Each row defines a single way point. Columns 1-11 contain: 

Column Description 

1 Way point X position (meters). 

2 Way point Y position (meters). 

3 Left screw speed command (volts). 

4 Right screw speed command (volts). 

5 Control mode flag, 0 = Depth control, 1 = Altitude control. 

6 Altitude command (meters, if applicable). 

7 Depth command (meters, if applicable). 

8 Perform GPS popup on this track, 1 = Yes, 0 = No. 

9 Duration of GPS popup (sec). 

10 Watch radius (meters) 

11 Way point timeout - mission aborts if ARIES has not reached the watch radius of the waypoint 
after heading for this waypoint for this amount of time (sec) 


Figure 23. Structure of ARIES Way Point File (After: Marco, 2001) 


The nonnal method to log in to ARIES’ computers is via 10Base2 ethemet 
connection to the QNXE/QNXT network. The operator uses network utilities such as 
telnet and ftp to control computer operations; retrieve, edit, and store computer fdes; 
compile the C code in which ARIES is programmed; and start and stop processes and 
missions. QNXE also provides two methods of communications with ARIES when it is 
physically disconnected from a computer network, as is the case during underway ARIES 
operations. A FreeWave radio modem connection via a serial port pennits an operator to 
take control and issue commands to QNXE when the FreeWave antenna is above the 
surface of the water during an operation. Additionally, ARIES’ acoustic modem is 
controlled by a process (fm) hosted by QNXE. The modem does not provide direct 
control of the QNXE processor, as does login over the FreeWave or 10Base2 Ethemet 

connection, but it does accept a limited set of commands defined in and recognized by the 
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fm and Exec processes. Such commands, if successfully parsed by the modem process, 
are written to modem shared memory where the Exec process reads and executes the 
command. Additionally, if the modem process successfully parses and passes on to the 
Exec process a pre-defined query for data, the processes obtain and write the requested 
data to the modem for transmission. 

F. HARDWARE MODIFICATIONS TO ENABLE RENDEZVOUS 

Because ARIES was designed to serve as a communications node, little hardware 
modification was necessary. The only change was installation of the electric current 
sensor which was used to determine the vehicle’s power characteristics. After measuring 
the necessary power data, this sensor remained in place as a development tool for future 
ARIES modifications. It is not necessary for actual rendezvous operations as 
implemented here. 

G. SUMMARY OF NECESSARY SOFTWARE MODIFICATIONS 

The basic navigational nature of QNXT processes required no modification. 
However, because of the command and control nature of QNXE processes, extensive 
modification was required in QNXE software. 

1. Dynamic, Autonomous Mission Planning Process 

As is the case with most AUVs, an ARIES mission is written and loaded into the 
vehicle prior to starting the mission. At the start of the mission ARIES parses the 
mission script file, which normally directs it to read the contents of the way point file into 
memory. The mission then consists of ARIES driving to each way point in a pre¬ 
determined sequence and manner. This relatively static mission definition is unsuitable 
for the rendezvous operations in that it does not permit ARIES to respond to rendezvous 
requests. To respond to a rendezvous request, ARIES operations must change once 
execution has begun. Beginning with a “loiter phase”, the operation must progress to a 
“closing phase” in response to a feasible rendezvous request. During the closing phase 
ARIES closes the position of the sensor or target vehicle. At the rendezvous point 
ARIES must transition to a “rendezvous phase”, during which it remains in close 
proximity of the target vehicle and conducts rendezvous communications. Finally, upon 
completion of rendezvous communications, ARIES must return to its loiter phase. These 

transitions, which involve timing and positioning which cannot be known a priori, require 
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dynamic, autonomous, on-board planning of the new mission. To accomplish this a new 
rendezvous planning process, named RPlan, was written to run concurrently and interact 
with a version of the Exec process modified for rendezvous to allow activation of new 
missions during an ARIES rendezvous operation. This modified process is named 
RExec. 

For baseline ARIES operations, involving the execution of a mission defined by a 
single waypoint file, the tenn “mission” refers to both the entirety of ARIES’ behavior 
during a single deployment as well as the contents of a single waypoint file. To avoid 
confusion in rendezvous ARIES terminology, where multiple “missions” may be 
executed during a single deployment, the term “mission” will refer to the contents of a 
single waypoint file. The term “operation” will refer to an ARIES deployment, during 
while several “missions” are expected to be executed. 

2. Additional Layer of Control 

The sequence of events involved in responding to a rendezvous request must be 
controlled by a higher level of logic than that of the base line ARIES or most other 
current AUVs. Whereas the typical AUV mission follows a sequence of waypoints or 
commands, rendezvous operations involve interpreting inter-vehicle communications, 
dynamic mission planning, error checking, multiple mission activation, and measures to 
provide robustness in the event of plausible problems. Management of such operations 
requires an additional layer of supervisory logic. In this implementation, a finite state 
machine was incorporated into the Exec process to monitor operation events and to shift 
ARIES mode of control of in response. 

3. Mission Activation 

Once written, the planned mission must be activated. In other words, its way 
points and other data must be read into Exec memory and the vehicle mission set to 
execute it. The baseline ARIES software performed this step once, at the beginning of its 
mission, with the mission consisting of proceeding to each way point in succession. 
Upon arriving at the final waypoint, the mission was terminated. For rendezvous, 
mission activation must take place mid-operation, whenever required by initiation or 
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completion of rendezvous. To accomplish this, Exec was modified to allow mission 
activation whenever required. Additionally, any of several way point files could be 
activated. 

4. Queue Management 

The asynchronous nature of the vehicle network required a queue in which to 
store incoming rendezvous requests. Additionally, typical queue management functions 
were necessary to perform such actions as testing for the presence of a request in the 
queue, clearing the top request from the queue once action is complete, or writing a new 
request to the bottom of the queue. Because queued rendezvous requests contained 
sensor vehicle navigation data, which could be updated by the sensor vehicle while the 
request remained queued, queue management in this implementation also need to 
distinguish between initial and subsequent rendezvous requests from the same sensor 
vehicle. In the former case, the request is written to the queue. In the latter, the initial 
request retains its position in the queue, with the navigation data contained in the request 
being overwritten by the updated data contained in the subsequent request. 

5. Shared Memory 

Shared memory is a method used by the QNX operating system to make data 
available between cooperating processes. Shared memory structures are initialized at 
boot-up, and may be accessed by multiple processes for reading or writing data. Before a 
process writes data to or reads data from a shared memory structure, it sets a semaphore 
to prevent ah other processes from accessing shared memory until the operation is 
complete. On completion it clears the semaphore, allowing access to the next process 
attempting to read or write to shared memory. Shared memory was already used 
extensively in ARIES prior to modification for rendezvous. Implementation of the 
rendezvous behavior resulted in addition of new variables to existing structures, as well 
as addition of a new structure to accompany the new mission planning process. 

6. Modem Upgrade 

As the conduit for rendezvous command-and-control communications, the 

modem process required modification. Some modification involved adapting its 

vocabulary to recognize messages required by the rendezvous process. However, the 

process was also rewritten to allow ARIES to initiate modem communications, something 
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ARIES Main Control Loop (8 Hz) 


Figure 24. QNXE Software Modifications to Implement Rendezvous. Baseline ARIES 

Features are Light. Proxy Trigger and Dark Features were Added for Rendezvous 
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it had not done before. In the past, ARIES modem transmissions had been only in 
response to modem queries from another modem. 

These software modifications are described in detail in the following sections. 
Figure 24 provides an overview of these modifications. 

H. MISSION PLANNING PROCESS 

1. Efficient Use of Computer Resources 

Adding a new process to the QNXE processor and its existing processes, 
especially one which potentially would involve extensive mathematical computations as 
well as file input and output, led to an early decision make the process as computationally 
efficient as possible. Were the addition of the planning process to consume the 
remainder of QNXE’s available resources, vital vehicle control functions in the Exec 
process such as autopilots could be disrupted. The following measures were taken to 
minimize the effect of the new planning process on existing QNXE processes: 

- The planning process was written as a separate process, rather than a function to 
be called by Exec. Although an analysis of QNXE loading indicated that a substantial 
amount of unused resources were available for a planning process, the computational 
requirements of such a process would be unknown until it was written. Writing the 
planning process as a separate process allowed the possibility of running it as a lower 
priority than other QNXE processes, a feature of the QNX 4.23a operating system. As a 
lower priority process, the planning process would use whatever QNXE computer 
resources were available once other processes were serviced. This is permissible since 
the planning of the rendezvous mission is less time critical than vehicle control functions. 

- The mission planning process was written such that it remained “receive 
blocked” until it was necessary to plan a mission. In this state, an inter-process control 
feature of the QNX 4.23a operating system, execution of the planning process is halted 
until it receives a signal from the RExec process. RExec sends this signal by triggering a 
QNX proxy message, which unblocks and starts the planning process. 
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- Wherever possible, planning calculations are performed prior to receipt of a 
rendezvous request to minimize calculations required during rendezvous request 
processing. Examples include calculating distances and courses between mission 
waypoints. 

Testing of the completed mission planning process showed that QNXE was 
capable of hosting the planning and existing QNXE processes with all processes running 
at the same priority. 

2. Data Required for Mission Planning 

A variety of data is required to plan the rendezvous between the ARIES and target 
vehicle; including ARIES vehicle dynamics, ARIES state infonnation, target vehicle state 
information, magnitude and direction of currents, and target vehicle mission parameters. 
This data can be divided into two categories: data onboard ARIES prior to the start of 
rendezvous mission planning, and data not onboard which must be included in the 
rendezvous request. 

An ARIES vehicle dynamics model can be written into the planning process. 
Also, ARIES estimates its own state, and that information is onboard at all times. 
Additionally, assuming that ARIES has the capability to measure and estimate currents in 
the area of operations, so that data is onboard as well. It may be obtained as the 
difference between velocity over ground and velocity through the water, both of which 
are measured by the Acoustic Doppler Current Profiler (ADCP). 

This leaves only target vehicle state information, some of which is assumed to be 
known a priori. As previously discussed, aspects of the target’s mission that are not 
expected to change during the operation are loaded onto ARIES prior to the start of the 
operation. In this implementation this infonnation was a sequential list of each target 
vehicle’s waypoints. Three elements described each waypoint: X coordinate (meters), Y 
coordinate (meters), and vehicle forward speed through the water u while closing each 
waypoint (meters per second) . Describing the target vehicle’s mission in this manner 
reduces the set of possible vehicle positions to a single segmented linear feature. 

The only remaining data required to plan the rendezvous is the target vehicle’s 
position along this path. This information generally will not be known to the server 
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vehicle unless the target vehicle is additionally constrained to maintain its progress along 
track in accordance with a pre-detennined time table, an overly restrictive requirement 
which would increase the complexity of target vehicle design and not allow for 
unforeseen disturbances to target vehicle progress. A simple and accurate way to locate 
a vehicle constrained to move along a path is to describe its location as its progress along 
the path. Progress is expressed as the present path segment being completed and the 
fraction of that segment complete. For this scheme a progress value of 0 represents the 
vehicle located at the start of a segment and 1 represents the vehicle located at the finish. 
Target vehicle progress is included in the rendezvous request as a method of locating the 
target vehicle, the remaining information required to plan the rendezvous is available 
onboard ARIES. 

3. Elements of a Rendezvous Request 

The rendezvous request consists of the following elements. All are integer values 
that are transmitted via acoustic modem to ARIES. 

a. Sender Identity 

Because multiple target vehicles may be involved in an operation, this 
element identities which vehicle sent the request. 

b. Present Track Segment 

This identifies which segment of its mission the target vehicle is presently 
completing, which is also the number of the way point at the end of the segment. As a 
result, way point “0” identities the starting point of the target’s track and “1” is both the 
first segment of the target’s track and the waypoint at the end of the track. 

c. Progress Along Present Track Segment 

This is a three-digit integer describing fraction of present track segment 
complete, expressed in thousandths. 

d. Time Stamp 

Target vehicle position must be accompanied by the time the position was 
detennined so that ARIES can correct the reported target vehicle position for time delays 
in transmitting and receiving the rendezvous request. Modem processing and sound 
propagation delays typically introduce several seconds of delay from transmission to 

reception and processing. This integer conveys the time for which rendezvous request 
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target vehicle state data was valid, in seconds since start of the operation. Note that this 
scheme requires synchronized clocks on ARIES and target vehicles. 

e. Check Sum 

Because an ARIES rendezvous mission is based on the information 
contained in a rendezvous request, because of the amount of data contained in the 
rendezvous request, and because of the likelihood that the rendezvous request may arrive 
garbled after long-range transmission between widely separated vehicles, a check sum is 
included in the rendezvous request. It is a simple sum of the four integers that precede it 
in the request. The check sum serves a second purpose in this demonstration of 
rendezvous behavior, where it is desirable to specify the optimization objective in the 
rendezvous request. To specify a time-optimal rendezvous the check sum is given a 
positive sign, while a negative check sum signals an energy-optimal rendezvous. For 
rendezvous operations outside of this demonstration, the particulars of the operation 
would determine whether time-optimal or energy-optimal rendezvous is desirable. In 
such cases this parameter would be set in ARIES prior to the operation, and would not be 
a necessary element of the rendezvous request. 

4. Pre-Processing Target Data 

The following calculations, which are perfonned on target data prior to the receipt 
of a rendezvous request, produce results that either will not change over the course of an 
operation or change slowly enough that they need not be repeated for each rendezvous 
request. This data is stored in a series of two-dimensional data arrays, with each row 
corresponding to a waypoint number and each column corresponding to a target vehicle 
number. Note that in the C programming language used in ARIES, the first element of an 
array is numbered “0”. Using this convention, the first waypoint of a mission is the “0 th ” 
way point, and the first row or column of a two-dimension array is the “0 th ” row or 
column. 

a. Compute Segment Lengths 

The Euclidean distance between each successive way point in a target’s 
mission is computed and stored in the array SegLen. Since the first segment of the 
target’s mission is the segment from waypoint 0 (first waypoint) to waypoint 1 (second 

way point), the first row of the SegLen array to contain computed segment lengths is row 
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1. Row 0 contains zeros, as there are only n-1 distances to compute between n way 
points. The first row of each of the following data arrays are also zeroes. 

b. Compute Segment Courses Over Ground 

The course over ground y/ a for each segment is computed as: 

V/ g =atan2(AT/^) (5.!) 

or, the arctangent of the ratio of change in Y coordinate and X coordinate between two 
successive way points expressed as a value between -pi and pi. These are stored in the 
array SegPsi 

c. Compute Target Vehicle Speed Over Ground and Heading for 
Each Segment 

In the absence of currents and other perturbations vehicle heading equals 
course over ground. However, rendezvous operations are assumed to take place in the 
presence of currents, and their effect is accounted for. Because the direction and 
magnitude of local currents vary slowly, their effects can be computed periodically on an 
appropriate time scale and considered constant between such updates. Doing so reduces 
the computations required in response to a rendezvous request. The target vehicle 
velocity over ground vector is the vector sum of velocity through the water and current 
velocity. Given the previous assumption that the target vehicle maintains its ground 
track, the known quantities of course over ground, current magnitude and direction, and 
speed through the water can be used to solve for vehicle heading and speed over ground. 
These quantities are stored in the two-dimensional arrays Psi and U_g, and are updated 
whenever magnitude and direction of currents are updated. 

5. Planning Time-Optimal Rendezvous 

The following is the sequence of events for a time-optimal rendezvous request, 
assuming that the received request is properly formatted and the planning process passes 
all checks. 

a. Validating Rendezvous Request Format 

Upon receipt by the acoustic modem, the header of any incoming message 
is compared against established message header formats to establish the type of message 
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received and to handle it accordingly. Once the incoming message is classified a 
rendezvous request message, the message is parsed into individual data elements which 
are written into corresponding modem shared memory variables. A flag in modem 
shared memory is also set to signal arrival of a recognized message type to the RExec 
process, which reads the message data from modem shared memory into the appropriate 
RExec process variables. 

Data received in the RExec process is checked against its check sum and 
written into the RExec rendezvous queue. At the appropriate time, as determined by the 
finite state machine, the request is retrieved from the rendezvous queue and computations 
begin which will result in a complete rendezvous mission waypoint file. 

b. Determining Future Target Vehicle Positions and Synchronizing 
Data 

To plan the rendezvous the planning process must adjust target position 
reported in the rendezvous request for delays in receiving the request and must project 
target position into the future. The method of accomplishing this begins with 
determining the expected time of arrival at each waypoint, beginning with the last way 
point reached by the target vehicle. For target vehicle i on segment j, this is way point j- 
1. The time t that the target vehicle arrived at this previous way point is computed as: 


t[i _ u = t U'rogntegLenijj}) 

L J -I stamp y t r • < 

U_g[j,i] 




Where Ktamp is 


the time stamp contained in the rendezvous request, Prog is the target’s 

fractional progress down the present segment ([j,i]) expressed as a number between 0 and 
1, and t is clock time of the operation at the time of computation, which was initialized 


at zero for all vehicles at the start of the operation. In general, t[j-l] has a negative value. 
This calculation removes the effects of delays in transmitting and processing the 
rendezvous request, thereby synchronizing the target’s state data to ARIES’ data . Also 
note that times produced by this calculation define the time of computation as t=0, so that 
all times are conveniently referenced to the time of computation. The target arrival times 
at way point [j] and subsequent way points are computed sequentially as: 
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t[j]=t[j- 1 ]+ 
t[j + 1 ] = t[j] + 


Seglen[j,i] 
U_g[j,i ] 
Seglen[j + 1 ,/] 

^.gt/' + U] 








( 5 . 3 ) 


Target future position and arrival time at each way point is now established. Using these 
discrete future positions and times as a basis, and knowing speed over ground for each 
segment, future target position can be determined for any future time, or target time of 
arrival can be determined for any future position along its track. 

c. Locating the Time-Optimal Rendezvous Point 
The next step in planning the time-optimal rendezvous is to identify the 
time-optimal rendezvous point, or, the earliest time that ARIES can rendezvous with the 
target vehicle. The method for finding this point is based on the concept of reachable 
states, as discussed in Ch. III. Locating this time-optimal rendezvous point proceeds by 
examining each future target vehicle way point and determining whether or not it lies 
within ARIES set of reachable states. Because ARIES dynamics envelope is assumed to 
always include those of the target vehicle, the problem timeline is divided into two 
periods. During an early period rendezvous is not feasible, usually because ARIES’ 
maximum speed does not allow it to reach the target vehicle by that time. During a later 
period rendezvous is always feasible. The boundary between these two periods is the 
earliest feasible rendezvous time, and only one such boundary exists. It is located by 
sequentially evaluating each of the target vehicle’s future waypoints and detennining 
whether ARIES can reach that point at the time the target is due to arrive there, on the 
same course and speed as the target, i.e., by determining whether rendezvous is possible 
at that point. The earliest way point for which rendezvous is feasible lies at the end of the 
segment that contains the time optimal rendezvous point, for the beginning point of that 
segment was a non-feasible point and therefore these two points bound the time-optimal 
rendezvous point. 
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Rendezvous feasibility for a given point on the target vehicle’s track 
consists of determining whether there is sufficient time for ARIES to transit to the point 
and match target vehicle course and speed, assuming ARIES transits at maximum speed 
and accounting for the time and distance required for ARIES to accelerate, turn as 
necessary, and decelerate to target speed. 

Such calculations require models of ARIES acceleration and deceleration 
(surge) and turn dynamics. An easily implementable and sufficiently accurate surge 
dynamics model suitable for this application was a first order linearly-damped model of 
the form: 

u(t) = u i + (u f -u i )e~' il (5.4) 

where it and u f are initial and final forward speeds, respectively. ARIES operational 

data showed the value of A to be approximately 0.2, yielding a five second time constant. 
This yields a speed model which can be easily integrated to compute the vehicle path 
length L required for the speed change: 

Z(0 = «/-^- L ( \-e lt ) (5.5) 

The exponential form of the above equation results in infinitely long path 
lengths since this representation for speed never exactly reaches steady state. To prevent 
this and to keep the result practical, the planning process considers the speed transient 
complete once ARIES speed is within 0.1 meters per second of its steady state value. 
The model’s fidelity with an actual ARIES speed transient is shown in Fig. 25. 

Similarly, a simple model of ARIES turn dynamics was necessary. The 
common empirically determined turn parameters for marine vehicles, advance and 
transfer, were used in this application and are shown in Fig. 26. Advance is the distance 
along the initial track that the vehicle travels during the turn, and transfer is the cross¬ 
track distance during the turn. These parameters describe the physical dimensions of a 
vehicle’s turn, allowing the rendezvous planning process to model turns when optimizing 
ARIES’ trajectory in a rendezvous mission. 
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Figure 25. Comparison of ARIES Speed Transient and First-Order Model 



Figure 26. 


Advance and Transfer 
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During a series of experiments these parameters and total ARIES turn path 
length were measured, and models fitted to the data. Path length, when combined with 
ARIES speed, determines the time to complete the turn. A cubic polynomial was fit to 
each data set: 

Advance = 3.178(A^) 3 -21.20(A^) 2 + 36.83(A^) (5.6) 

Transfer = -0.3837(A^) 3 + 0.6694(A^) 2 +9.362(A^) (5.7) 

PathLength = 3.345(A^) 3 -17.67(A^) 2 + 37.01(A^) (5.8) 

These functions are shown in Fig 27. 



Figure 27. ARIES Advance, Transfer, and Path Length Versus Course Change 

Using the above models, along with information on set and drift due to 
currents, the time and change in position required for each ARIES turn is computed by 
the planning process RPlan, as shown in Fig. 28. 
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Figure 28. Calculating Effects of Course/Speed Changes With Currents. Large Course 
Change (a). Small Course Change With Speed Change Continuing After Course 

Change (b) 


As discussed in previous chapters, these turns comprise the beginning 
and end of ARIES’ closure trajectory for rendezvous. The remaining portion of the 
trajectory is a straight, steady-course, steady-speed segment between the two turns. It 
covers the period from the end of the initial course and speed change to the beginning of 
the final course and speed change. Hence, the ARIES trajectory is computed as three 
consecutive and separate segments tied together by boundary conditions on course, 
speed, and position at four key points. Starting at ARIES’ initial position (X ; ,Ij) with 

initial course y/ 1 and initial speed u,; point 1 (Aj, Ij) is the end of the initial course / 

speed change maneuver and the start of the straight portion of the trajectory where 

ARIES course and speed are i// ! and u x respectively. Point 2 (X 2 ,Y 2 ) is the end of the 

straight portion of the trajectory and the start of the final course / speed change maneuver. 
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Note that i// 2 = i//, and a 2 = u l . Point 3 (X 3 ,Y 3 ) is the rendezvous point. At this final point 

ARIES position, course, and speed match those of the target vehicle. The ARIES 
rendezvous trajectory is shown in Fig.29. 

Target 



Figure 29. ARIES Rendezvous Trajectory 

The process of planning ARIES’ speed changes is fairly straightforward. 
The initial speed change takes ARIES from its initial speed, u j , to the speed during the 

straight portion of closure, i\. Recall that for minimum time rendezvous u, is ARIES’ 
maximum attainable speed. 

For the sake of simplifying ARIES mission planning, both ARIES’ final 
turn and final deceleration begin at point 2. This is a deviation from the results of the 
previous chapters, which in general did not require simultaneous final course and speed 
changes. This simplification avoids such complexities as planning a way point during the 
final turn to begin deceleration, without significantly altering the optimization of the 


71 



rendezvous trajectory. This does not occur during the initial turn since course and speed 
changes begin simultaneously at the beginning of this turn. The result of this simplified 
planning of the final turn is that ARIES either steadies on final course while decelerating, 
or reaches final speed while completing the turn, neither of which lead to significant sub- 
optimization. 

The process of determining whether a target vehicle future waypoint is 
feasible begins by computing the effects of each course / speed change on ARIES 
trajectory. The advance, transfer, and path length are calculated for each turn. The path 
length required for the speed change is also calculated, using Eqn. 5.8 above. Whichever 
path length is longest determines the duration of the course / speed change transient. If 
the course change is significant, the turn path length dominates. Conversely, when minor 
course changes are made, the dominant consideration becomes the distance required to 
reach the steady state speedy. In the former case, (X 1 ,Y X ) are found by displacing 

(X i ,Y i ) the distance due to the effects advance and transfer, plus the distance due to 
currents over the time duration of the turn. For the latter case, (Aj, Ij) are found by 
displacing (A., F.) the distance due to the effects advance and transfer, plus the additional 
distance along the final course y/ x required to complete the speed transient, plus the 

distance due to currents over the time duration of the turn. These are shown in Fig. 28. 

A similar approach is used for the final turn / speed change, except whereas the initial 
turn projected the effects forward from the initial known position, in the final turn the 
final position is known or assumed and these effects are projected backwards to find 
(X 2 J 2 ). 

One complication to the above methodology is that the effects of neither 
turn can be calculated directly since each is a function of course change, a quantity that is 
unknown since it depends on the combined effects of both turns. For example, to find 
(Xj,7j), advance and transfer data are applied to (X i ,Y i ). However, advance and transfer 

depend on ARIES course between (X v Y x ) and (X 2 ,Y 2 ), which depends on the unknowns 
(Xj,7j). To overcome this complication, an iterative solution is used in the planning 
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process starting with an initial guess for the u nkn own course y / 2 . This guess is the 
heading i// 2 such that the current-corrected course over ground connects (X i ,Y i ) to 
(X 3 ,7 3 ), ARIES’ initial and proposed final positions. Using this initial guess, initial 
values of (Xj,7j ) and (X 2 ,Y 2 ) are obtained, which yield a refined value of y / t . Iteration 
continues until neither X 2 nor V 2 change by greater than 1 meter in the last iteration. 

The above iterative algorithm fails to converge when ARIES is ahead of 
the target vehicle and within an ARIES turn diameter of the target vehicle’s projected 
track, as illustrated in Fig. 30. 



a. b. c. 

Figure 30. ARIES on Target Track Causes Planning Non-Convergence. Initial Computation 
of Transfer (a). First Refinement Iteration (b). Result of First Iteration(c) 

In this case the planning process plans a final turn that is essentially a course reversal, but 
in excess of pi radians. In calculating the advance and transfer of any turn, the planning 
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process compares the initial and final headings and computes advance and transfer. The 
difficulty stems from the computation of transfer which, unlike advance, has sense. 
Advance has the same value whether a course change of given magnitude goes to the 
right or left of initial course. In computing transfer for a given course change, the 
direction of the course change must be noted so that the planning process applies transfer 
in the direction of the turn. For the case of ARIES near the target track, the final course 
change is approximately a full course reversal and is in excess of pi radians. In planning 
a turn, given an initial and final course, the two choices are to turn less than pi radians, in 
the direction of the next course, or to turn greater than pi radians, in the opposite 
direction, then to steady on the new course. The former is normally desirable, and is the 
method used in the planning process. On the initial computation of transfer for the final 
turn, a comparison of y/ 2 and '//, yields a value of transfer with the correct sense, as 

shown in Fig. 30(a). However, on the first iteration to refine the position of (X 2 ,Y 2 ), i/a 
is compared with the just-determined y / 2 , which is based on the initial value of transfer. 
As shown in Fig. 30(b), the comparison of y/ 2 with y/ 3 yields a reversal of the sense for 
transfer, due the shortest turn between these two courses. Applying this value of transfer 
to ( X 3 , T,) in the backwards direction to locate (X 2 ,Y 2 ) shifts this point to the opposite 
side of the target’s track. This results in another final turn in excess of pi radians, and in 
the course of planning this turn the opposite effect occurs, switching ( X 2 ,Y 2 ) back to the 
original side of target track and never converging. To prevent non-convergence, 
whenever ARIES initial position is within 30 meters of target track the iterative process 
of locating ( X x , Y t ) and( X 2 ,Y 2 ) stops after one iteration. This single iteration first plans 
initial and final course changes based on target course and the course between the known 
locations (X i ,Y i ) and( X 3 ,Y 3 ). The result is a loss of a few meters in accuracy, which 

may be reduced during subsequent replanning of the rendezvous mission. 

If ARIES total transit time exceeds the time at which the target vehicle is 
due at this waypoint, the target’s state at this time is not contained in ARIES set of 
reachable states, and rendezvous is not feasible. In this case the time-optimal rendezvous 
point occurs later, further down the target vehicle’s track. Conversely, if the calculated 
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ARIES transit time is less than the time that the target vehicle requires to reach the way 
point, rendezvous is feasible at this point, albeit suboptimally as ARIES can feasibly 
arrive before the target. In this case, the time optimal rendezvous occurs at an earlier 
time and location along the target’s track. 

Having detennined the time required to complete both course / speed 
changes and the endpoints of the straight portion of the trajectory, t ]2 , the available 

ARIES transit time between (A 2 ,7 2 ) and (A,,L) is computed by subtracting the time 
required by both ARIES course/speed changes from the time that the target reaches the 
way point. The final step in determining rendezvous feasibility is to compare R x _ 2 , the 

distance between (A,, T,) and (A,,7 2 ), to R A , the maximum distance ARIES could 
travel in along i//, from (A,,K,) and ( A 2 ,7 2 ) in t x _ 2 while correcting for prevailing 
currents. In the time optimal case, 

(5-9) 

as ARIES reaches the rendezvous point at the earliest possible moment. Locating the 
time-optimal rendezvous point therefore consists of finding the zero of 

*,-*,_ 2 (5-10) 

The zero is located iteratively using a secant-method algorithm (Betts, 2001). 

d. Locating Remaining ARIES Way Points 

The process of locating the time-optimal rendezvous point (A 3 ,7 3 ), the 
first way point found for the ARIES rendezvous mission, also locates the way point for 
beginning the final course / speed change (A 2 ,7 2 ) as an intermediate result. The 
remaining rendezvous mission way points are added prior to (A 2 ,7 2 ) as GPS fix way 
points, or after (A 3 , Y ,) to guide ARIES along the target vehicle’s track. In this 
implementation the first three target way points after (A,, 7) were used in ARIES 
rendezvous mission to provide a sufficiently long rendezvous communication period. 
The number of GPS way points included prior to rendezvous is a function of/?, 2 , which 
constitutes the majority of ARIES pre-rendezvous travel. GPS waypoint planning 
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consists of dividing the straight track between (X x ,Y x ) and (X 2 ,Y 2 ) into 200 meter long 
segments, starting at (X 2 ,Y 2 ) and stepping backwards towards X,, Y x . ARIES surfaces for 
a GPS fix once in each 200 meter segment. A GPS fix is also planned in the segment 
between the earliest 200 meter segment and (X v Y x ) if that segment is at least 100 meters 

long, which provides sufficient time for the surfacing maneuver and course correction 
following the fix. 

e. Planning Speeds 

As shown in Fig. 23, each ARIES mission waypoint is specified by 11 
parameters. Having detennined the values in the first two columns for each waypoint in 
the time optimal rendezvous mission, X and Y coordinates, the remaining are then 
assigned. The next two columns contain N rs and N ls , the speed commands to the right 
and left thrusters respectively, which detennine ARIES forward speed through the water 
u. Since the relationship between propeller speed and forward speed for vehicles such as 
ARIES is typically linear, experimental ARIES data was used to establish a linear 
relationship between thruster commands and commanded speed u com : 

N,,N rs =2A32u com (5.11) 

Identical commands are sent to both thrusters. Experimentation with ARIES showed that 
its maximum speed is approximately 1.5 meters per second, so for time-optimal 
rendezvous waypoints up to and including (X 2 ,Y 2 ) speed corresponding to 1.5 meters per 
second is commanded. This results in ARIES using maximum speed from the start of the 
rendezvous mission until it reaches ( X 2 ,Y 2 ), the point at which it begins its deceleration 

to match target speed. For way points after ( X 2 ,Y 2 ), the speed command is the same as 
the target’s speed. 

f Setting Way Point Timeouts 

ARIES is programmed to abort its mission if it does reach its way point in 
a specified time period. This provides for mission termination in the event of a vehicle 
control or navigation failure. This feature, controlled by the parameter in the final 
column of the way point file, was left unmodified for this implementation, so it was 
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necessary to assign appropriate values to this parameter. Values of approximately 150% 
of expected time to reach each waypoint were assigned to each, a rule validated by 
previous ARIES research. 

g. Planning GPS Fixes 

As discussed above, GPS fixes may be planned prior to the rendezvous 
point. For each segment containing a GPS fix, the value in column 8 is set to “1” and the 
value in column 9 is set to 30, to allow a 30 second period in which to surface and obtain 
the fix. 

h. Setting Watch Radii 

This parameter determines when ARIES is considered to have reached the 
way point. When ARIES approaches the way point within this distance, or crosses a line 
perpendicular to the track connecting the current and previous way points and tangent to 
the watch radius circle, the next way point is activated and ARIES begins driving towards 
it. A typical value for this parameter is 10 meters, the value which is set for most way 
points and the value assumed to be used by the target vehicle. The exceptions are 
(X,,7 2 ) and (X 3 ,7 3 ), which define the entry into and exit from the final turn. In order to 
accurately control ARIES trajectory during the final turn into the rendezvous, these watch 
radii are set to 1 meter. 

i. Setting Depths and Altitudes 

These parameters are set in columns 5-7 of the way point file. Depth 
mode is selected in column 5 to maintain ARIES at a constant depth, which is set to 3 
meters in column 6. Since altitude mode is not set in column 5, column 7 represents 
unused data for nonnal depth-mode ARIES missions. For this implementation this 
column is used to indicate whether ARIES is expected to be rendezvoused with the target 
at this time, an indication that triggers other ARIES actions. Therefore, for all waypoints 
after (X 2 ,Y 2 ) this value is set to “7” to indicate rendezvous should be in progress. 
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Figure 31. Watch Radius 

j. Writing the Mission to File 

Once all rendezvous mission parameters have been assigned, the mission 
is checked for feasibility by verifying that each planned way point lies within the 
previously determined area of operations. Once checked, the mission is written to the 
way point fde “RdvzTrack.ouf’, which is opened and executed by the RExec process. 

6. Planning Energy-Optimal Rendezvous 

The steps to planning an energy-optimal rendezvous are a superset of the steps for 
planning a time-optimal rendezvous. All the time-optimal planning steps - finding the 
time optimal rendezvous point, planning GPS fixes, setting speeds and other parameters, 
checking for feasibility, and writing the mission to file - are taken; however energy- 
optimal rendezvous planning involves additional complexity requiring additional 
intermediate steps. 

a. Bounding the Energy-Optimal Rendezvous Point 

Whereas the time optimal rendezvous point was uniquely defined as the 
position of the target vehicle at the earliest time for which the target state was included in 
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ARIES set of reachable states, the energy optimal rendezvous point is one of many 
possible reachable states. This is so because, by its nature, the energy optimal 
rendezvous involves closing the target at a slower, more energy-efficient speed. As was 
the case with time-optimal rendezvous, the target state is not included in the set of 
reachable states prior to the time-optimal rendezvous point, therefore the time-optimal 
rendezvous point sets the earliest possible bound for the energy-optimal rendezvous. 
This provides the planning process a wide range of possible rendezvous points, all of 
which lie after the time optimal rendezvous point. 

The energy optimal rendezvous point lies somewhere in a single region 
that is bounded by this point and another similar point. Practical limits on slow-speed 
vehicle controllability define this latest-possible bound on energy optimal rendezvous 
when it occurs prior to end of target mission. Because vehicles such as ARIES use 
control surfaces to generate forces to control attitude, course, and depth; and because 
these forces are proportional to the square of forward speed, there exists a practical 
minimum speed u min below which the forces generated by its control surfaces can no 

longer overcome buoyant forces, surface suction forces, or other disturbances. This 
minimum speed sets a lower bound on propulsion power, and results in an upper bound 
on time for energy-optimal rendezvous. Minimum ARIES speed sets a lower bound on 
minimum energy used for rendezvous: 

E= '\ A+BuiJl = t,(A+Bu^) (5.12) 

1 =0 

where t : . is the time of rendezvous, A is vehicle hotel load in watts, and B is the 

propulsion power coefficient in watt-second 3 / meter 3 . Since the tenn in parenthesis is 
constant, the minimum energy to rendezvous is a linear function of time. As a result, if 
there exist multiple opportunities to rendezvous with ARIES closing the target at u min , all 

opportunities after the first opportunity require more energy. As a result, the earliest 
rendezvous time for ARIES using its minimum speed throughout the closure to 
rendezvous sets a latest possible time for minimum-energy rendezvous. The minimum 
energy rendezvous point lies between the first time that the target’s state is included in 
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ARIES set of reachable states at maximum ARIES speed and the first time it is included 
at ARIES minimum speed, as shown in Fig. 32. 


Outer Boundary of 
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• ARIES Initial Position • 


a. b. 

Figure 32. Earliest Possible Energy-Optimal Rendezvous (a). Latest Possible Energy 

Optimal Rendezvous (b) 

There are two exceptions to the above result. First, if the target vehicle’s 
mission terminates prior to the time that ARIES could reach it at minimum speed then 
obviously the latest possible rendezvous time is the end of the target’s mission. Second, 
in a similar situation, if the target continuously opens ARIES position at a speed higher 
than u min , ARIES cannot reach the target before the end of the target mission. However, 

this is unlikely since target vehicles are assumed to remain in within a bounded 
geaographical area, meaning their overall speed away from ARIES is likely to be low. 

Bounding the times of possible minimum energy rendezvous conserves 
computational resources required for the energy optimal rendezvous by limiting the size 
of the space to be search for a solution. 
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b. Locating the Energy-Optimal Rendezvous Point 
This process uses the same subroutines used to find the time-optimal 
rendezvous point. First, the time-optimal rendezvous point is located on the target 
vehicle’s track, marking the earliest possible time for energy optimal rendezvous. 

After this step the sequence of steps for planning the energy-optimal 
rendezvous trajectory departs from the time-optimal sequence. The next step in the 
energy-optimal planning process is to identify the latest possible energy-optimal 
rendezvous. The same algorithm is used, except whereas the earliest time was identified 
by setting ARIES speed to its maximum value of 1.5 meters per second, the search for 
the latest time is conducted using ARIES minimum speed of 1.0 meters per second. 

Having defined the portion of the target’s track containing the minimum 
energy rendezvous point, the track is sampled to determine the energy required to 
rendezvous at each sample point. For each sample point the speed to reach that point is 
computed as trajectory path length between ARIES and the point, divided by the time the 
target vehicle will be at the point. The energy required by the rendezvous trajectory to 
that point is then calculated for each point as 

E = (A + Bu 1 )t (5.13) 

and the minimum energy rendezvous point is identified as the point having the lowest 
value of E. 

Once the minimum energy point is identified, the planning process plans 
the trajectory from ARIES position to the rendezvous point. The process is similar to that 
of the time-optimal case, which used a constant speed to iteratively locate the rendezvous 
point. However, in this case the rendezvous point is held constant while the course and 
speed changes necessary to reach the point are solved iteratively. 

Having determined the energy-optimal rendezvous point, the remainder of 
the planning process is identical to that for the time-optimal rendezvous. Additional way 
points are added to the mission and waypoint parameters are set for each waypoint, only 
difference being that ARIES speed command prior to the rendezvous point is a lower, 
energy-efficient speed rather than maximum attainable speed. The mission is checked for 
feasibility, and written to the way point file RdvzTrack.out. 
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I. STATE MACHINE 

Having provided ARIES the capability to autonomously reconfigure its operations 
by planning new missions in response to requests by other vehicles, it was necessary to 
add another layer of logic above that of baseline ARIES. The form selected was a finite 
state machine, illustrated in Fig. 33. The finite state machine is a representation of a 
process consisting of states and transitions (Hatley, Hruschka, and Pirbhai, 2000). In the 
ARIES state machine, each state is a stage of the rendezvous process. Associated with 
each state are actions taken by the vehicle. Transitions between states occur in response 
to events sensed by the vehicle. Each state is responsive to a specific set of events, with 
no action taken for events not associated with that state. Each state also has an associated 
set of transitions it may take to the next state. The finite state machine provides a clear 
framework upon which to define the logic of the rendezvous process, and provides a high 
level of control over the process. This is essential since it is now necessary to automate a 
multi-state ARIES mission, containing both previous ARIES processes as well as new 
and modified processes. 

The state machine comprises a new, third layer of control above two layers that 
existed in the vehicle prior to this work. The three-layer approach is common in robotics 
software architecture, with the Rational Behavior Model (RBM) (Kwak, McGee, and 
Bihari, 1992) representing one implementation. In ARIES the lowest layer, 
corresponding the execution level of the RBM, contains the autopilots that control the 
vehicle’s fins and rudders to keep the vehicle on prescribed course and depth, which 
reside in the process RExec. The middle layer, corresponding the RBM tactical level, 
contains the mission control functions, also resident in the RExec process. This logic 
interprets the mission script and waypoint files and sequences the vehicle though the 
mission defined in these files. Mission parameters contained in these files are provided 
to the execution level for action. The state machine, representing the strategic level of 
the RBM, sequences ARIES through multiple missions during its operation and performs 
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Figure 33. ARIES Finite State Machine, Showing States and Transitions 
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supporting functions such as initiation and interpretation of communications and 
initiation of mission planning. This hierarchy is shown in Fig. 34. 



Figure 34. ARIES Three-Layer Rendezvous Software Architecture 

The state machine is implemented in ARIES RExec code by defining the variable 
“State” and changing its value whenever criteria are met for transition to the next state. 
There are seven possible states, and with transition criteria and actions defined for each. 
At each 125 millisecond cycle of RExec’s main control loop the transition criteria are 
examined. If satisfied, the state transition occurs by the next cycle. 

1. Loiter 

LOITER is ARIES’s initial state upon starting the RExec process. 
a. Actions 

While in LOITER, ARIES follows the way point file “Track.out”. This 
behavior is the same as baseline ARIES behavior, except for mission timeout, providing 
backward compatibility with baseline ARIES missions. To run a baseline ARIES 
mission under rendezvous software architecture, one need only define the mission in the 
mission script file script.d and way point file Track.out and run the mission under RExec 
without issuing any rendezvous requests to ARIES. 
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For rendezvous missions the way point file Track.out defines ARIES loiter 
location, courses and speeds. In general ARIES loiters at low, energy-efficient speeds, 
fixing its position periodically with GPS. 

Any transition to LOITER reactivates the way point file Track.out. 

b. Transitions 

While in LOITER, ARIES checks the status of the rendezvous request 
queue each 125 millisecond cycle of the RExec control loop. ARIES remains in the 
LOITER state as long as the queue remains empty, transitioning to the mission planning 
PLAN MSN state as soon as a request appears in the queue. 

There are three transitions into the LOITER state. If ARIES is in the 
RENDEZVOUS state, the LOITER state is entered upon completion of the rendezvous. 
If, while attempting to initiate rendezvous communications, ARIES cannot contact the 
target vehicle, it returns to the LOITER state. If the rendezvous planning process 
produces an infeasible rendezvous mission, the state returns to LOITER. Note that 
whenever rendezvous requests exist in the queue prior to ARIES entering the LOITER 
state, ARIES immediately transitions to the PLAN MSN state. 

2. Plan Mission 

a. Actions 

Upon entering the PLAN MSN state, RExec writes the parameters 
contained in the next rendezvous request in the queue to RExec shared memory. This 
makes the request available to the rendezvous mission planning process RPlan. RExec 
then triggers RPlan’s proxy, which frees the RPlan process from its normal “receive 
blocked” execution-suspended condition and begins the mission planning process. On 
subsequent control loop cycles RExec monitors the status of the planning process, which 
is indicated by values written to RPlan shared memory by the RPlan process, and take 
actions based on the outcome of the planning process. 

b. Transitions 

There are five transitions into the PLAN MSN state. The previously 
discussed transition from the LOITER state occurs for initial planning of a mission in the 
rendezvous request queue. The remaining four are due to replanning a rendezvous 

mission in progress in order to improve navigational accuracy. If a subsequent 
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rendezvous request is received from the same target vehicle that ARIES is closing for 
rendezvous, but before the rendezvous commences, the updated target position data 
contained in the request is used to replan the mission by reentering the PLAN MSN state. 
Similarly, if ARIES is unable to establish rendezvous communications with the target 
vehicle after arrival at the rendezvous point, it queries the target for its position. The 
position contained in the response to the query is used to replan the mission. Whereas 
these allow replanning to correct target vehicle position, there are two instances when the 
rendezvous mission is replanned to correct for ARIES position. Whenever ARIES 
obtains a new GPS fix, subject to a restriction that no GPS fix has been obtained within a 
specified time period, replanning occurs. Finally, replanning occurs if ARIES fails to 
obtain a scheduled GPS fix. Although in such cases no new position data is obtained to 
improve the accuracy of ARIES’ position, disturbances such as currents and speed 
variations will perturb ARIES as it drives down its track towards rendezvous. Periodic 
replaning allows ARIES to adjust its rendezvous plan to ensure it meets the target at the 
rendezvous point. 

There are two transitions out of the PLAN MSN state. As discussed 
above, when the rendezvous planning process produces an infeasible mission, state 
transitions to LOITER. In addition, the rendezvous request is cleared from the queue so 
that the next request may be acted upon. On the other hand, if the mission planning 
process produces a feasible mission, RExec opens the rendezvous mission way point file 
RdvzTrack.out, reads the contents into memory to begin executing the rendezvous 
mission, and ARIES enters the CLOSING state. 

3. Closing 

ARIES is in the CLOSING state from the time it begins executing a rendezvous 
mission until it reaches the rendezvous point, with the exception of transitions to the 
PLAN MSN state for replanning. 

a. Actions 

While closing the rendezvous point ARIES monitors replanning criteria. 
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b. Transitions 

The CLOSING state is entered upon successful completion of mission 
planning. Transition out of the closing state occurs for replanning or arrival at the 
rendezvous point. 

Replanning in response to a subsequent rendezvous request from the 
current target vehicle occurs when the queue management process detennines that this 
has occurred. 

Replanning in response to a good GPS fix begins after an unbroken ten 
second period of receiving three or more GPS satellites, if no GPS fix has been obtained 
in the previous 60 seconds. The 60 second period ensures that once such a GPS fix 
period exceeds 10 seconds, the planning process is not repeatedly triggered each RExec 
cycle. The ten second/three satellite criterion is based on previous ARIES navigation 
system performance. Note that failure to meet this fix criterion does result in rejection of 
the GPS fix data. Although replanning does not occur if the criteria are not met, ARIES 
navigation is still updated by the GPS data and the correction of ARIES position still 
occurs in the navigation filter. This updated navigation data will then be applied to the 
next mission replanning event. 

If a GPS fix satisfying the above criteria is not obtained, a 30 second timer 
is started. If no GPS fix is obtained in this period, replanning commences. 

Upon arrival at ( X 2 ,Y 2 ), the start of the final course/speed change, ARIES 
transitions from the closing state to the initiate rendezvous or INIT RDVZ state. Arrival 
at this point is signaled by the activation of the way point (X 3 ,7 3 ). It, and all subsequent 

way points in the rendezvous mission, contain the value “7” for the 6 th way point 
parameter. This is the state machine transition signal. 

4. Initiate Rendezvous 

a. Actions 

Upon entry into this state, ARIES attempts to initiate rendezvous 
communications with the target vehicle which should be nearby. 
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b. Transitions 

The INIT RDVZ state is entered upon activation of the rendezvous point 
as the next ARIES way point. 

The state is exited either when rendezvous communications are 
established with the target vehicle, or after no rendezvous communications occur after 60 
seconds. 

5. Rendezvous 

a. Actions 

In the rendezvous or RDVZ state, ARIES conducts rendezvous 
communications while it continues to follow the rendezvous mission. 

b. Transitions 

The state is entered at the start of rendezvous communications, and is 
exited at their completion. 

6. Query Position 

Should ARIES be unable to establish rendezvous communications within 60 
seconds of entering the INIT RDVZ state, it enters the query position or QUERY POSIT 
state and attempts to locate the target vehicle, the assumption being that it is not in the 
immediate vicinity, outside the limited range of the high-bandwidth rendezvous 
communications device. 

a. Actions 

ARIES transmits a query to the target vehicle, asking it to send an updated 
rendezvous request with which ARIES may plan a new rendezvous mission. 

b. Transitions 

The state is entered at the expiration of a 60 second timer from the INIT 
RDVZ state. It is exited if no response to the query is received. In this case, ARIES 
enters the LOITER state. If a response is received, the state becomes PLAN MSN. 

7. Terminate 

When the operation involving ARIES and its network of sensor vehicles reaches 
its scheduled completion, ARIES’ logic must tenninate this phase of the operation and 
activate the final phase: returning for recovery. To do so, ARIES enters the 
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TERMINATE state. This state is unique in that it can be entered from any state, which 
provides a “fail-safe” feature to break ARIES out of whatever phase of operations it may 
be involved in. 

a. Actions 

Upon entry into the TERMINATE state, ARIES activates the way point 
file TerminateTrack.out, which brings ARIES to its recovery point. Periodic GPS fixes 
are obtained enroute to maintain accurate navigation. 

b. Transitions 

The state is entered upon expiration of the mission timer. There are no 
transitions out of the state. 

8. Receipt of Rendezvous Requests and Other Modem Messages 

The asynchronous operations of the vehicle network result in rendezvous request 
transmission at any time. The state machine ensures that ARIES acts on requests only 
when appropriate, however incoming requests must be properly handled at any stage of 
the operation. To ensure this occurs, the state machine portion of the RExec process 
takes the same action on incoming requests regardless of state. Within the RExec 8 Hz 
control loop, immediately before the state machine block of code, the RExec process 
reads modem shared memory to check for arrival of any new modem message. Arrival of 
a new message is signaled by the modem process Rfim setting one of its shared memory 
variables, an integer that serves as a flag, to TRUE. If set, the data contained in the 
message is read from modem shared memory into RExec. 

If the message is a rendezvous request or pertains to rendezvous communications, 
the value of the RExec variable “SMEvent” , or state machine modem event, is set to 
signal this event. It can signal four different events: receipt of a rendezvous request 
requiring immediate planning, receipt of a rendezvous request to be queued for later 
planning, start of rendezvous communications, and completion of rendezvous 
communications. The value of SMEvent is an input to the state machine to potentially 
trigger a state transition. 

If the modem message is a rendezvous request, the checksum is validated and the 
request written to the queue. 
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Any abort command received by the modem process triggers a bock of code 
which immediately brings ARIES to the surface and shuts it down, bypassing the state 
machine. 

If the message is a position query, it is processed by the modem Rfm process 
without involving the RExec process. 

9. Initiating Modem Transmissions 

The state machine periodically generates outgoing modem transmissions. 
Because ARIES carries only its Benthos modem, with no high data-rate rendezvous 
communications equipment, this modem serves both command and control and simulated 
data functions. As a result, all communications go through this one modem. 

As discussed previously, ARIES transmits to attempt to begin rendezvous 
communications, and transmits to query for target position if rendezvous communications 
do not start within the expected time. In an actual operation, as opposed to this 
demonstration, the former would be transmitted as short-range data communications and 
the latter as long-range command and control communications. 

For the purposes of this development and demonstration additional modem status 
messages are initiated by the state machine to supplement the above transmissions to 
better track vehicle status, although they would not be used in an operational setting. 
These transmissions are shown in Table 1. 

J. MISSION ACTIVATION 

The baseline ARIES execution process Exec opened one way point file at the start 
of its mission, loading data into memory and performing necessary calculations only 
once. Calculations include such parameters as courses and lengths of each segment, time 
out for the first way point based on ARIES initial position, and whether the first way 
point is too close and should be skipped. The RExec process required the flexibility to do 
this mid-operation, whenever a new mission is activated by the state machine. To this 
end, these functions were removed from RExec and rewritten as a distinct subroutine of 
RExec which could be called whenever necessary, taking the way point file name and 
ARIES position as input arguments. 
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MODEM TRANSMISSION 

TRANSLATION 

“ CLOSING” 

Successful completion of the mission 

planning or replanning. 

“INFEASRDVZ, LOITER” 

Mission planning resulted in an infeasible 

rendezvous mission plan. 

"QUERYPOSIT TIMEOUT” 

Rendezvous attempt abandoned after no 

rendezvous communications established and 

no response received in response to query 

for target vehicle position. 

"RDVZ COMMS” 

Entry into the rendezvous state 

"MISSION TIMEOUT, TERMINATING” 

Overall mission timeout. 


Table 1. Modem Messages Initiated by the State Machine 


K. RENDEZVOUS QUEUE AND QUEUE MANAGEMENT 

The rendezvous queue is an integer array sized to store five rendezvous 
parameters for each of four rendezvous requests. The size of the queue was based on an 
assumption that no more than four target vehicles would be involved in the operation, and 
due to queue management which allows only one queued request per target vehicle. 
Requests. The five parameters per request are target number, waypoint, progress towards 
way point, time stamp, and check sum/optimization objective. 

The first queue management function, WriteQueue, writes incoming the requests 

to the queue when they appear in modem shared memory. Because subsequent requests 

from a queued target vehicle represent updated navigation information and not a request 

for an additional rendezvous, the process of writing to the queue also involves checking 

the queue for a previous request from this target vehicle. If no previous request is queued 

for this vehicle, the request is written to the bottom of the queue, otherwise the previously 

queued request is overwritten. WriteQueue returns a value which becomes the value of 

the state machine variable SMEvent. If the queue is empty, there are no pending 
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rendezvous requests and the incoming request should be sent to the mission planning 
process immediately. Similarly, if the sending vehicle’s previous request is at the top of 
the queue, ARIES is in the process of rendezvousing with the sender of the incoming 
request. As long as the present state is not RENDEZVOUS, the incoming request should 
be processed and the rendezvous mission replanned. For these two cases SMEvent is set 
equal to “2”, which triggers the mission planning process if ARIES’ state is LOITER, 
CLOSING, or QUERY POSIT. Otherwise it returns the value “6”, which causes the 
contents of the request to be written to the queue. 

The queue management function “CheckQueue” is called by RExec while in the 
loiter state to initiate mission planning. CheckQueue returns “1” if there is a pending 
rendezvous request in the queue, otherwise it returns “0”. 

The queue management function “ClearQueue” removes the top request from the 
queue and promotes all pending requests. It is called upon nonnal completion of a 
rendezvous, upon completion of the mission planning when the mission is infeasible, and 
after an unsuccessful rendezvous when ARIES fails to make contact with the target 
vehicle and receives no response to its query for target vehicle position. 

L. MODEM 

The baseline modem process “fm” was rewritten as “Rfm” to support rendezvous 
operations. Its vocabulary was modified to remove unused message formats and to 
provide those required. Recognized incoming messages are shown in Table 2. 
Recognized message headers are “RVS” and “RVQ”, corresponding to “set” commands 
and queries, respectively. The next field in the message is the command, which is 
followed by command parameters in the case of a rendezvous request. Memory variables 
were also added to store message parameters. Receipt of any of these messages causes 
the contents to be written to Rfm shared memory, and for a flag to be set in shared 
memory to signal the RExec process that a new message has been received. RExec clears 
this flag after reading the message parameters from Rfm shared memory. 

The modem process was also modified to allow the RExec process to initiate 
modem transmissions, as is necessary when ARIES attempts to contact the target vehicle 

or transmit status messages. This required the Rfm process to monitor the contents of 
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MESSAGE 

TRANSLATION 

' R VS, RE Q,a,b,c,d,e” 

Rendezvous request from target vehicle a, which is enroute to 
its b th way point and is located c thousandths of the total 
length of this leg down track at time d seconds. The sum of 

the integers a-d is e. The sign of e is positive for a time- 

optimal rendezvous and negative for an energy-optimal 

rendezvous. 

"RVS,CS” 

Start of simulated rendezvous communications 

“RVS,CC” 

Completion of simulated rendezvous communications 

“RVS, ABORT” 

Abort. ARIES stops and surfaces. 

“RVQ,POSIT” 

Query ARIES X,Y position 


Table 2. Incoming Messages Recognized by Modem Process 


RExec shared memory as well as modem output. Rfm checks the status of a flag in 
RExec shared memory which signals the presence of an outgoing message, at 
approximately 20 Hz. When this flag is set, Rfm reads the message from RExec shared 
memory, clears the flag, and sends the message to the modem to be transmitted. 

M, SHARED MEMORY 

Shared memory is the primary method of inter-process communications in 
ARIES. Modifications to shared memory for rendezvous operations consisted of creating 
a new shared memory segment for the planning process RPlan, and adding new variables 
to the existing execution and modem process shared memory segments. A diagram of 
shared memory segments is shown in Fig. 35. 
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Figure 35. Shared Memory Segments and Variables 

The RExec process makes data available to the modem processes Rfm and RPlan. 
Data made available to the modem consists of a flag to signal the RExec has generated an 
outgoing modem message and the message itself. RExec sets the flag and Rfm clears the 
flag once it reads the message. RExec also makes data necessary for mission planning 
available to RPlan. This data consists of ARIES position, course and speed, target 
parameters for the target to be rendezvoused with, and clock time. RExec shared memory 
also makes provisions for passing measured current set and drift, although measurement 
of these parameters is not yet implemented in RExec code. 

Rfm shared memory provides a flag for modem messages similar to that in RExec 
shared memory. It is cleared by the RExec process once the incoming message is read by 
RExec. The remaining Rfm shared memory variables store the data contained in the 
incoming message. 
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RPlan shared memory contains flags to indicate that the mission plan generated 
by the planning process is ready, and whether it is feasible. The plan ready flag is cleared 
by RExec after it reads the flag. Additionally, RPlan shared memory contains the process 
identification of its proxy. This value must be provided to the RExec process in order for 
RExec to trigger RPlan’s proxy to start the planning process for each rendezvous request. 

N. SYSTEM IN-LAB TESTING 

The extensive modifications to ARIES software required significant debugging 
and verification of proper perfonnance. New features and processes were written and 
tested as isolated modules. However, meaningful complete testing of the integrated 
system of existing and new code required full-up mission execution. Mission execution 
normally requires in-water operations, since the lab environment does not provide proper 
inputs to ARIES’ navigation sensors to simulate expected progress through a operational 
scenario. In the lab environment baseline ARIES software generates multiple mission 
abort signals because in-lab sensor readings detect events such as failure to reach way 
points, exceeding minimum allowable altitude above bottom, or thruster failure. 

In-water testing also has its limitations. As well as being expensive, labor- 
intensive, and dependent on weather conditions, it is also less efficient. It is not possible 
to remain logged on to ARIES’ QNXE and QNXT processors during an in-water run 
since no network connection is available with ARIES underway on a mission. The result 
is that it is significantly more difficult and time-consuming to monitor mission execution, 
diagnose improper execution, reboot processors when necessary, and modify and 
recompile code during in-water ARIES operations. 

To overcome these difficulties and accelerate implementation of rendezvous 
operations, an in-lab testing mode was included in the code for the RExec process. By 
doing so, the following ARIES protective actions could be temporarily disabled for in-lab 
testing, then restored for in-water operations: 

Minimum altitude abort: If ARIES altitude above bottom falls below a set 
minimum, it suspends execution of its mission, turns to a pre-determined 

course towards deeper water, runs at high speed for a set period, and aborts its 
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mission. In the lab sensed altitude equals zero since ARIES acoustic doppler 
current profiler is in air, triggering this abort. 

Way point time out abort: If ARIES position does not satisfy watch radius 
criteria before expiration of the associated way point time out; a navigation, 
propulsion, or control failure is assumed. Abort criteria is met and ARIES 
tenninates its mission. 

Additionally, in-lab operation of thrusters generally involves running them in air, 
which risks damaging them due to lack of cooling and lubrication. 

The following features were implemented in RExec to overcome these 
impediments: 

A variable called “LAB” was defined, which is set to “1” for in-lab testing 
and “0” otherwise. The minimum altitude abort function is enabled only 
when LAB=0. 

Simulated navigation data is programmed into RExec code which overwrites 
the navigation data received from the nav process running on QNXT. Data 
such as (X,Y) position is provided as a function of time to simulate ARIES 
progressing through a sequence of way points. This not only allows execution 
of a simulated in-water mission, it prevents activation of the way point 
timeout abort. Additionally, other parameters can be simulated to verity other 
features of ARIES software. In particular, the number of GPS satellites 
received was simulated as a function of time to verify that expected 
rendezvous mission replanning occurred following GPS fixes. 

Thruster speed command was made to be contingent on the value of LAB. 
When equal to 1, thruster speed command was reduced by a factor of 10 to 
pennit in-air operation. 

In-lab testing consisted of approximately 200 missions to debug ARIES 
rendezvous software. As a result, with the exception of compass error and a minor 
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conflict between two methods of periodic mission replanning, ARIES demonstrated 
expected rendezvous behavior upon its first attempt in-water. 
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VI. DEMONSTRATION OF CONCEPT 


A. METHODS 

Demonstration of ARIES’ capability to perfonn the server vehicle function was 
accomplished via two methods. 

Using the capability to run missions in the laboratory environment developed for 
this work, rendezvous missions were run in the laboratory with simulated navigation data 
provided to the vehicle. Navigation data consisted of a pre-programmed sequence of 
vehicle positions, as well as course, speed, and number of GPS satellites. These 
simulated parameters provided sufficient input to ARIES rendezvous software to evaluate 
its perfonnance. All vehicle systems, including thrusters, control surfaces, and sensors 
operated normally during lab testing. Actual acoustic communications were used for 
sending commands to ARIES and for ARIES to transmit when required. 

Actual in-water missions were used to further demonstrate ARIES’ capabilities. 
Because a second AUV with compatible acoustic communications capabilities was not 
available, demonstration of the rendezvous concept involved ARIES rendezvousing with 
a virtual target vehicle. This target consisted of a moving point in space whose position, 
course, and speed are programmed prior to the run and could be determined in post-run 
analysis. While target movements were simulated, actual target communications other 
than high bandwidth data transfer communications were provided by a Benthos acoustic 
modem controlled by a human operator on a nearby support vessel. It injected all 
communications that would have been transmitted by the target vehicle, providing 
simulated target vehicle communications for ARIES to process and respond to. Such 
communications included actual rendezvous requests as well as short messages signaling 
the start and completion of simulated high bandwidth data transfer communications. 
Additional utility messages commanded ARIES to report its position or to abort its 
mission. 

Geometry of the operational area is shown in Fig. 36. For in-water operations, 
ARIES started in a 100 meter square loiter pattern, periodically obtaining GPS fixes to 
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maintain navigational accuracy. For laboratory operations it was not necessary for ARIES 
to maintain headway while awaiting a rendezvous request, so the initial position was a 
single point. 

In all demonstrations the target vehicle was assumed to follow a typical survey 
pattern of advancing parallel tracks. 
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Figure 36. ARIES Demonstration Setup 

B. STATE MACHINE AND RENDEZVOUS QUEUE, LABORATORY RUN 

Proper operation of the state machine and rendezvous queue was tested early in 
the development process, first as MATLAB code, then as stand-alone C code on ARIES, 
and finally as C code integrated with all rendezvous software. All combinations of states 
and input events were applied to ARIES to verify that proper action was taken when 
expected, no action was taken when no action was expected, and that repeated 
occurrences of the same event did not cause ARIES to take repeated actions. Tables 3 
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through 6 list a sequence of events run in the laboratory and ARIES’ correct response to 
each. ARIES’ initial state was LOITER, with the loiter mission plan active. 


Event 

ARIES Response 

1. Invalid rendezvous request 

None. 

2. Valid rendezvous request 

Written to queue. State change to PLAN MSN. 

3. Plan is complete, infeasible 

State change to LOITER, request cleared from queue. 

4. Valid rendezvous request 

Written to queue. State change to PLAN MSN. 

5. Plan is complete, feasible 

State change to CLOSING. Rendezvous plan 

activated 


Table 3. ARIES Laboratory Mission 1, Events 1-5. 


Event 1 is a receipt of a rendezvous request that did not meet the parsing criteria 
of the RExec process. Here that the check sum was incorrect for the remaining data 
contained in the request. As a result, the request was disregarded and ARIES’ operation 
was unchanged. 

Event 2 modified event 1 in that the check sum criteria was met. In response, the 
request was written to the rendezvous queue by the queue management function 
WriteQueue. This caused a state transition to PLAN MSN, and processing of the request 
by the planning process RPlan. Here, the resulting plan did not pass the RPlan feasibility 
check (event 3). RPlan signaled RExec that the planning process was complete, but that 
the plan was infeasible. As a result, RExec called the ClearQueue queue management 
function to remove the request from the queue, and the state changed back to LOITER. 

Event 4 modified event 2 in that the resulting plan was feasible (event 5). In 
response, the state machine set the state to CLOSING and activated the rendezvous 
mission plan just created by RPlan. 
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Event 6 was receipt of a signal that rendezvous communications had commenced. 
This was inserted to verify that no response to this event whould take place in the 
CLOSING state. 


Event 

ARIES Response 

6. Rendezvous comins start 

None. 

7. Replanning timer expires 

State change to PLAN MSN. 

8. Plan is complete, feasible 

State change to CLOSING. 

9. Arrival at rendezvous point 

State change to INIT RDVZ. Attempt comms. 

10. No comins received from 

State changed to QUERY POSIT. Queries target for 

target 

present position. 

11. No target position received 

State change to LOITER, loiter mission plan 

activated, rendezvous request cleared from queue. 


Table 4. ARIES Laboratory Mission 1, Events 6-11. 


Event 7 was the expiration of the replanning timer, which occurs when a GPS fix 
is scheduled during the CLOSING state but no satisfactory fix is obtained. This caused a 
state transition to the PLAN MSN state, and subsequent reentry to the CLOSING state 
and activation of the new mission upon successful replanning of the rendezvous mission 
(event 8). 

Event 9 was arrival at rendezvous, which caused transition to the INIT RDVZ 
state. In this case ARIES attempted to start rendezvous communications, but rendezvous 
communications were not received from the target vehicle (event 10). This triggered 
transition to the QUERY POSIT state, wherein ARIES signaled the target vehicle to 
send an updated rendezvous request. In this case, ARIES received no reply to its query 
(event 11), causing transition to the LOITER state. Along with the state transition, the 
loiter mission plan was activated, and the rendezvous request was cleared from the queue. 
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Event 12 was another valid rendezvous request; which resulted in successful 
mission planning, transition to the CLOSING state, and activation of the rendezvous 
mission written in response to this request (event 13). This was followed by event 14, 
which was a valid rendezvous request from a different target vehicle. Because ARIES 
was currently enroute to rendezvous with the first target vehicle, this request from a 


second vehicle was written to the 

queue for later processing. 

Event 

ARIES Response 

12. Valid rendezvous request 

Written to queue. State change to PLAN MSN. 

13. Plan is complete, feasible 

State change to CLOSING. Rendezvous plan 

activated 

14. Valid rendezvous request 

from different target 

Written to queue under current request. 

15. Rendezvous comins 

complete signal 

None. 

16. Arrival at rendezvous point 

State change to INIT RDVZ. Attempt comms. 

17. No comins received from 

target 

State changed to QUERY POSIT. Queries target for 

present position. 

18. Updated target position 

received 

State changed to PLAN MSN 

19. Plan is complete, feasible 

State change to CLOSING. Updated rendezvous 

plan activated. 


Table 5. ARIES Laboratory Mission 1, Events 12-19. 


Event 15 was similar to event 6, an event that should elicit no response from 
ARIES because ARIES was not in the state for which action should be taken. Because 
the state was CLOSING, vice RDVZ, no action was taken. 
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Events 16 and 17 were the same as events 9 and 10, except in this case the target 
vehicle replied with a new rendezvous request reporting its present status (event 18). 
This caused another transition to PLAN MSN, and upon event 19 ARIES transitioned 
back to the CLOSING state and activated the updated rendezvous mission. 


Event 

ARIES Response 

20. Arrival at rendezvous point 

State change to INIT RDVZ. Attempt comms. 

21. Rendezvous comins start 

State change to RDVZ 

22. Rendezvous comins 

complete 

Current request cleared from queue. Next request 

promoted to top of queue. State changed to LOITER, 

then to PLAN MSN when request noted in queue. 

23. Plan is complete, feasible 

State changed to CLOSING. Rendezvous plan for 

second target activated. 

24. Mission timer expires 

State changed to TERMINATE. Terminate plan 

activated 


Table 6. ARIES Laboratory Mission 1, Events 20-24. 


Event 20 was arrival for rendezvous, which in this case was immediately followed 
by rendezvous communications (event 21). Communications complete was signaled by 
event 22, which caused transition to the LOITER state, clearing of the rendezvous request 
from the queue, promotion of the subsequent rendezvous request to the top of the queue, 
and activation of the loiter mission. However in this case the transition was only 
momentary, as the state machine detected the presence of a rendezvous request during its 
next cycle, and ARIES planned and executed the rendezvous for this target vehicle (event 
23). 

Event 24 was the expiration of the overall mission timer, which immediately 
activated the terminate mission and causes ARIES to transit to its recovery site. 

C. TIME-OPTIMAL RENDEZVOUS, LABORATORY RUN 
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Having demonstrated the proper functioning of ARIES’ state machine and queue 
management software, laboratory runs were conducted to verify proper functioning of the 
planning process RPlan and of ARIES in general. The initial configuration of both 
vehicles is shown in Fig. 37. ARIES was in the LOITER state, on course 000 true, speed 
0 meters per second, and the rendezvous queue was empty. The target vehicle was on its 
fifth mission leg, between way points 4 and 5, on a westerly course, with a speed of 1.0 
meters per second. 
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Figure 37. Mission Planning, Time-Optimal Rendezvous, Laboratory Run 

At time = 34.25 seconds ARIES received the following message via acoustic 
modem: 

RVS,REQ,0,5,120,30,155 

which was parsed by the modem process Rfm as shown in Table 7. 
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This constitutes a valid message, and was written to the rendezvous queue. With 
ARIES in the LOITER state and a rendezvous request in the queue with a positive check 
sum, the state machine triggered the planning process RPlan to build a time-optimal 
rendezvous plan. The time-optimal mission planning process proceeded as discussed in 
Ch. V. RPlan retrieved the target vehicle mission from memory, and applied the 4.25 
second transmission time delay from generation to receipt 


Message Element 

Translation 

RVS,REQ 

Rendezvous request 

0 

Target vehicle number 0 is the sender of the request 

5 

Target vehicle is enroute to its waypoint number 5 

120 

The target vehicle is 120/1000 (12.0%) down the track from its 

waypoint number 4 to its waypoint number 5 

30 

The data contained in the rendezvous request are target vehicle 

parameters at time = 30 seconds. It is 4.25 seconds old 

155 

Check sum. Since this has a positive value, a time-optimal 

rendezvous is requested. 


Table 7. Parsing of Laboratory Time-Optimal Rendezvous Request 

of rendezvous request to the times that it calculated for target vehicle arrival at its 
previous and subsequent way points. The planning process identified the first way point 
at which ARIES could feasibly rendezvous with the target vehicle. In this case, it was the 
present waypoint, waypoint 5. Using the iterative method of finding the time-optimal 
rendezvous point between this way point and the previous way point, the planning 
process identified points 1, 2, and 3. Point 3 is the rendezvous point and the point at the 
end of the second course/speed change. Point 2 is the start of this course / speed change, 
and point 1 is the end of the first course / speed change. Because the first course / speed 
change involved a minor 4.33 degree course change but a significant 1.5 meter per 
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second speed change, its duration was determined by the 13.5 seconds required for 
ARIES to accelerate. Once on steady course and speed, ARIES trajectory between point 
1 and 2 was a straight line 178.7 meters long which, at 1.5 meters per second, could be 
transited in 119.1 seconds. The final course / speed change was a significant 94.33 
degree course change and minor 0.5 meter per second speed change, so its duration was 
determined by the 26.0 seconds required to complete the turn. As a result, the plan 
brought ARIES to point 3, the rendezvous point, 158.6 seconds into the future, at which 
time it should match target vehicle course and speed. Its position along the track at that 
time was projected to be Y=500.9, which was 0.3 meters ahead of the target vehicle’s 
projected Y=501.2 position. With velocities and positions matched, the vehicles meet the 
definition of rendezvous. 

Using these points, the planning process created the rendezvous mission described 
by the way point file shown in Table 8, which is in the ARIES format of the previous 
chapter. The first two way points are points 2 and 3. Note that the distance to the first 
waypoint is greater than 100 meters, so that a “1” appears in the eighth column to obtain 
a GPS fix during this leg to update ARIES’ position. The final three waypoints are the 
next three target waypoints, waypoints 5, 6, and 7. 
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0 

7.00 

3.00 

0 
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450.00 

850.00 

400.00 

2.13 

2.13 

0 

7.00 

3.00 

0 

1.00 

10.00 

75.00 

850.00 

700.00 

2.13 

2.13 

0 

7.00 

3.00 

0 

1.00 

10.00 

450.00 


Table 8. ARIES Initial Rendezvous Mission, Laboratory Time Optimal Run. 

ARIES activated this rendezvous mission, and at time = 75 seconds its simulated 
position was greater than 30% of the way down the first leg of its rendezvous mission, 
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which contains a GPS pop-up. Having met GPS pop-up criteria it surfaced, and at that 
point began to sense the simulated reception of three GPS satellites. In accordance with 
the GPS reception logic written into the RExec process, after ten seconds of this GPS 
reception rendezvous mission replanning occurred. The situation is shown in Fig 38. 
Because ARIES’ GPS position was different from its position had precisely followed the 
course and speed of its rendezvous trajectory, it was necessary to replan the rendezvous 
based on updated vehicle positions. This is done as it was done above, and the result was 
a new time-optimal rendezvous point. Note that ARIES position was further from the 
rendezvous point than was expected, which lengthened the time remaining until the 
earliest possible rendezvous. As a result, the updated rendezvous is later, 10.6 meters 
further down the target’s track. 

950 

900 

850 

.c 

o 

z 

w 800 

i> 

to 

2 

750 

700 

650 


I I 

Final 

Rendezvous Point 
c (900.0, 490.3) 

5 

i i i i 

Original Rendezvous Point 
(900.0,500.9) 

1 

4 


Start Final Course / Speed Change 
| (881.8,504.8) 


- 

1 

- 

- 

ARIES Expected Position 

(759.1, 505.7) 

o 

- 


AFtlES GPS Position 
(750,500) 


_[_[_ 

_ 1 _ 1 _ 1 _[_ 

_[_ 


400 450 500 550 600 650 700 

Meters East 


Figure 38. Mission Replanning, Time-Optimal Rendezvous, Laboratory Run. 
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Following replanning of the rendezvous mission, ARIES continued on to the 
rendezvous point. The next several events and ARIES responses were nominal, as 
presented in the previous section and shown in Table 9. 


Time 

Event 

ARIES Response 

(Sec) 



180 

Arrival at rendezvous point 

State change to INIT RDVZ. Attempt comms. 

189 

Rendezvous cormns start 

State change to RDVZ 

200 

Rendezvous comins 

complete 

Current rendezvous request cleared from queue. 

State changed to LOITER, loiter mission activated. 


Table 9. Events and Responses Following Mission Replanning, Time-Optimal Laboratory 

Run. 

The final event of this run was a GPS popup while ARIES was enroute to the 
loiter pattern. Since mission replanning applies only to the rendezvous mission and can 
only occur while ARIES is in the CLOSING state, the loiter mission is unaffected. 
Although the mission waypoint file remains unchanged, the fix provides data that updates 
ARIES’ position and improves its navigation accuracy. 

D. ENERGY-OPTIMAL RENDEZVOUS, LABORATORY RUN 

The initial conditions for this run were identical to the time-optimal run. At time 
= 34 seconds ARIES received the following message via acoustic modem: 

RVS,REQ,0,5,120,30,-155 

This is identical to the rendezvous request from the time optimal run, except the check 
sum’s negative sign signals that the rendezvous will be planned as energy optimal. As 
discussed in Ch. V, the initial portion of the energy-optimal planning process is to 
determine the time-optimal rendezvous point, which establishes the earliest bound on the 
time period during which an energy optimal rendezvous may occur. Because the target 
vehicle position data contained in this rendezvous request is identical to the time-optimal 
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case, and the time delay for receiving this request was only 0.25 seconds different from 
the time-optimal case, the earliest possible energy-optimal rendezvous point was 
essentially the original time-optimal rendezvous point bound from the previous case. 
Therefore the earliest possible rendezvous occurred on target mission leg 5. 

As discussed in Ch. V, the latest possible energy-optimal rendezvous is found as 
the time optimal rendezvous for ARIES’ lowest speed, 1.0 meters per second. Sampling 
the target track every 20 meters between these two bounds and determining the energy 
required for rendezvous at each point yielded the point (900,420) as the energy optimal 
rendezvous point, as shown in Fig. 39. 
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Figure 39. Energy to Rendezvous versus Rendezvous Position, Energy-Optimal Laboratory 

Run 

After locating the energy-optimal rendezvous point, the planning process built the 
rendezvous mission waypoint file to get ARIES to the rendezvous point. This planning 
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process is similar to that used in the time-optimal case, except instead of adjusting the 
rendezvous point location with closure speed fixed, closure speed is adjusted while 
holding the rendezvous point fixed. The process is illustrated in Fig. 40. 
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Figure 40. Mission Planning, Energy-Optimal Rendezvous, Laboratory Run 

After ARIES activated the rendezvous mission, the rendezvous proceeded as in 
the time-optimal case, with the mission replanned once in response to a GPS fix. 

E. TIME-OPTIMAL RENDEZVOUS, IN-WATER RUN 

The initial in-water time optimal run is depicted in Fig. 41. ARIES began the run 
in the loiter state, traversing its loiter pattern in a clockwise direction and fixing its 
position with GPS periodically. At time = 662.125 seconds, ARIES received the 
following rendezvous request from target number 2: 

2,2,96,660,760 
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This request parses to a time-optimal request from target #2, located 9.60% of the way 
between its waypoints 1 and 2 at time 660 seconds. As before the planning process 
identified the time-optimal rendezvous point, which in this case was located on the third 
leg of the target’s mission. The mission was feasible and ARIES departed its loiter 
pattern to begin closing the rendezvous point. 



Figure 41. Time-Optimal Rendezvous, In-Water Run 

At time = 782.375 seconds ARIES replanned the rendezvous mission. During 
closure ARIES actual speed through the water had been 1.6 meters per second, not 1.5 
meters per second as planned by the planning process. This was due to ARIES’ open- 
loop speed control. Ballasting and hydrodynamic variations resulted in a higher than 
expected speed. Mission replanning took this speed difference into account, adjusting the 
rendezvous point for ARIES actual position which was further down track than expected; 
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and using the better-than expected progress towards the rendezvous point to plan a new, 
earlier rendezvous. The result was a four degree course adjustment to the left, towards 
the earlier rendezvous point. 

At time t = 909 seconds ARIES arrived at the rendezvous point X=950, Y=617.3. 
Projecting the target vehicle’s rendezvous request position forward to this time, its 
position would be X=950, Y=903.8. Therefore ARIES arrived approximately 5.2 meters 
ahead of expected position of the target vehicle. This miss distance is within range of all 
present high-speed underwater communications systems, and was primarily due to the 
speed error during closure. ARIES’ accumulated position error due to the 0.1 meter per 
second speed error during the 127 seconds of closure since mission replanning would 
have been approximately 13 meters. 

ARIES controls and state responses are shown in Fig. 42. As discussed in Ch. Ill, 
rudder control is “bang-singular-bang” while enroute to rendezvous, with approximately 
zero rudder during the singular arc. Speed control is “bang-bang”. 


Rendezvous Request 


Rendezvous 


to 

i 


S’ 

T3 

CD 

■o 

T3 

3 

Cd 


co 

c 

"O 


X 



Time (sec) 
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ARIES rendezvoused with the target for 120 seconds. At the rendezvous point 
ARIES unsuccessfully attempted to establish rendezvous communications, which were 
provided by a modem-equipped support vessel. As a result, ARIES queried for target 
vehicle position at time = 976.625 seconds. When no reply was received by time =1036 
seconds ARIES abandoned the rendezvous attempt, as directed by the state machine, and 
returned to its loiter area. 

F. ENERGY-OPTIMAL RENDEZVOUS, IN-WATER RUN 

The initial in-water energy-optimal run is depicted in Fig. 43. 



Figure 43. Closure for Energy Optimal Rendezvous, In-Water Run 

ARIES again started in its loiter pattern. At time = 242 seconds it received the 
rendezvous request 

RVS,REQ,0,7,500,240,-747 

which signaled that the target number 0 was 50% of the way down its seventh leg at time 
240 seconds, and that the rendezvous will be energy optimal. The planning process 
identified three candidate rendezvous points at which rendezvous fell within ARIES 
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speed range. The leftmost point required the least energy, and rendezvous was planned 
for that point. Replanning occurred at two later times based on reception of satisfactory 
GPS fixes scheduled to occur at those points. The first replanning resulted in selection of 
the same rendezvous point as initial planning. Due to variations in actual ARIES speed 
and external disturbances during closure, the second replanning process selected the 
center candidate rendezvous point. Shortly after this final replanning of the rendezvous, 
ARIES aborted its mission due to inadequate battery power for propulsion. Projection of 
ARIES’ and the target’s future movements indicated that the vehicles would have 
rendezvoused within approximately 30 meters. 
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VII. CONCLUSION 


A. SUMMARY 

This work develops a high-bandwidth concept for accelerating access to 
information gathered by AUVs. This cooperative behavior enhances AUV operations 
and increases their value and effectiveness in networked naval operations as envisioned 
in the UNO’s “Sea Power 21” guidance for future Naval operations. 

The data transfer method utilizes rendezvous between AUVs to enable the use of 
high bandwidth optical or acoustic communications links between vehicles. A server 
vehicle, whose role is to transfer survey data from sensor vehicles to a larger network, 
comes into close proximity with a sensor vehicle to receive the data. This is necessary 
because high bandwidth underwater communications methods are of limited range, This 
concept also provides a greater degree of covertness than radio links with the sensor 
vehicle. 

Because of limitations on AUV energy resources, and because access to such data 
may be time-sensitive, efficiency is a goal of the rendezvous process. Since most 
literature on rendezvous deals with spacecraft operations, intercept methods were 
investigated for application to AUV rendezvous. Intercept is similar to rendezvous in 
that the goal is to match the future position of a target vehicle. Rendezvous imposes the 
additional constraint that target vehicle be matched as well. Doing so brings both 
vehicles in close proximity with no relative motion such that communications can be 
exchanged. The relative merits of intercept methods are dependent on the geometry of 
the particular problem, owing to the lack of information on target maneuvers during the 
intercept. This work demonstrates how such information, which should be available 
between cooperating vehicles, enhances the efficiency of the rendezvous process. 

Efficiency was then defined as time-optimal or energy-optimal rendezvous, 

depending on whether the objective is the most rapid access to data or conservation of 

vehicle energy reserves. Using principles of optimal control, the characteristics of the 

optimal rendezvous trajectories were determined for both cases. For time optimal 

rendezvous the solution was found to be bang-singular-bang rudder control and bang- 
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bang speed control. The chaser vehicle immediately accelerates to and maintains 
maximum speed until such time that stopping propulsion causes the vehicle to decelerate 
to target vehicle speed at the rendezvous point. It also executes two course changes, 
using maximum rudder until on a heading to close the target vehicle and remaining on 
this heading until a final maximum rudder turn that brings it to the position and heading 
of the target vehicle at the same speed. The rendezvous point is uniquely defined as the 
earliest for which the target vehicle’s state fall into the set of chaser vehicle reachable 
states. In order to detennine the energy-optimal rendezvous trajectory, the vehicle’s 
power requirement as a function of speed must be known. Installation of a current sensor 
in the NPS ARIES vehicle made this possible for the ARIES vehicle, and data showed 
that the vehicle’s power characteristics are a typical combination of a constant hotel load 
and a cubic propulsion load. The energy-optimal rendezvous solution involves bang- 
singular-bang control of both speed and rudder. Rudder control is similar to the time- 
optimal case, while speed control involves a final speed change to match target speed and 
an initial speed change to a most-efficient speed to close the target. This speed is 
dependent on problem geometry, and may not be attainable due to lower limits on vehicle 
speed imposed by vehicle buoyancy and control considerations. The minimum energy 
solution is not unique, but operational considerations would probably drive towards 
selecting the earliest of multiple solutions. 

These solutions were then implemented by upgrading the operational software of 
the ARIES vehicle to allow it to perform the server vehicle function. Whereas ARIES is 
a typical AUV utilizing autopilots for vehicle control and mission scripts and way point 
files to define a mission, rendezvous requires a higher level operational control. In order 
to rendezvous, ARIES must communicate effectively with the other vehicle, must plan its 
mission based on infonnation received from the other vehicle, must activate the mission 
and follow it to the rendezvous point, must periodically replan the rendezvous mission to 
account for navigational changes enroute, must provide a level of robustness to deal with 
navigational and communications failures, and must properly sequence this complex 
collection of activities. 
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ARIES communications software was upgraded to allow exchange of rendezvous 
information and to allow ARIES to initiate communications. 

A mission planning module was written to process incoming requests to 
rendezvous, combine the infonnation contained in the request with pre-stored target 
vehicle mission parameters, and generate a rendezvous mission waypoint file to bring 
ARIES efficiently to the rendezvous point in either a time-optimal or energy-optimal 
manner. 

ARIES mission activation software was rewritten to allow activation of way point 
files whenever appropriate, rather than only at the start of a mission as is typically the 
case with AUV missions. Additionally a rendezvous queue, along with queue 
management routines, was added to coordinate the processing of requests from multiple 
target vehicles. 

To coordinate ARIES’ rendezvous operations an additional layer of control was 
added. A finite state machine was implemented which defined the rendezvous mission as 
a series of seven states. The state machine defined a series of mission events, and 
ordered state transitions to occur whenever transition criteria were met. 

ARIES proper functioning as a server vehicle capable of rendezvousing with 
other vehicles was then verified. A laboratory operational mode was developed for 
ARIES, allowing ARIES to run simulated missions in the laboratory environment. This 
greatly reduced the amount of time needed to debug the significant code changes 
necessary to perform rendezvous operations, and provided a means to demonstrate 
ARIES proper operation as a rendezvous-capable server vehicle. In-water runs with a 
surrogate target vehicle and using a support vessel to provide communications inputs to 
ARIES further demonstrated ARIES correct functioning as a server vehicle. 

B. RECOMMENDATIONS 

This work developed and demonstrated the server vehicle rendezvous behavior on 
the ARIES AUV, however an operational system would require the following additional 
developments. 
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A high bandwidth communications link should be installed on the server vehicle 
to provide the high-speed data transfer capability that is the motivation for this work. 

Implementation of closed-loop control of server vehicle speed would improve 
navigation to the rendezvous point. This implementation used open-loop speed control 
based on previous determination of the relationship between steady-state thruster and 
vehicle speeds. Closing this loop, particularly for energy-optimal rendezvous, would 
improve the server vehicle’s ability to reach the rendezvous point at the computed time of 
rendezvous. In the time-optimal case, since the objective is to rendezvous as soon as 
possible, a logical and analogous improvement would be to command maximum vehicle 
speed as was done here, but to use actual measured speed in the rendezvous planning 
process. This would still provide minimum-time transit to the rendezvous point, while 
providing more accurate data to the planning process. 

Because of the limited range of high-bandwidth underwater communications 
equipment, it would be beneficial for server vehicle navigation to shift to a mode based 
on sensed survey vehicle position once rendezvous is achieved. The implementation 
presented here is based on a global frame of reference for both vehicles, wherein the 
accuracy with which the server vehicle can close the survey vehicle is affected by the 
global position uncertainty of both vehicles. At best, several meters of error would be 
expected if using typical global navigation methods such as GPS or long-baseline 
acoustic navigation. However once the rendezvous point is reached using a global 
reference frame, if the server vehicle is able to sense the position of the survey vehicle 
directly and shift to a navigation frame of reference centered on it, the server vehicle 
should be able to control its position relative to the survey vehicle with accuracy superior 
that of the global reference frame. This may be necessary for extremely short range or 
highly directional communications systems. 

Compatible survey vehicles must be added to the operation to create the vehicle 

network. Such vehicles should be configured with both command-and-control mode and 

rendezvous mode communications equipment, and this equipment must be integrated 

with the vehicle’s processors. Vehicle logic must determine when an event warranting 

transmission of a rendezvous request has occurred, determine vehicle state, generate the 
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request containing the state information, and transmit it. Logic should also determine 
when to issue subsequent rendezvous requests if rendezvous does not occur. Rendezvous 
mode communications equipment must be integrated with the sensors gathering survey 
data, to transfer the data once rendezvous commences. 

Survey vehicles should also be dynamically compatible with the server vehicle so 
that rendezvous is possible. The survey vehicle should not operate at speeds greater than 
the server vehicle, and turn dynamics should be compatible so that rendezvous operations 
are not unduly disrupted during turns. Additionally, for directional communications 
systems, the motions of both vehicles must be controlled to avoid disruption of the 
communications link during data transfer. 
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